[tz] [english 99%] Re: [PROPOSED] Support zi parsers that mishandle negative DSToffsets
mhochschild at gmx.de
Sat Feb 10 16:14:16 UTC 2018
Although most Java users like me and millions other really appreciate
your work very much, I fear you don't fully understand how Java world
works/ticks. The big majority of Java users is not willing to run any
shell scripts or macros just because it would not be compatible with the
major goal to create platform-independent Java software. So the only
real primary interface from the perspective of a Java user consists of
the source code files like "Africa", "Europe" etc. I myself can surely
not use your macro "Make" because that would require me and other users
of public Java APIs to download extra non-Java-software components even
on unknown future platform-specific environments. It is only interesting
for those Java users who just develop private-only tools for a known
specific platform but this is clearly a minority.
And I still think that extra source code files with documented reliable
formats would far more serve the specific needs of Java users without
the need to change the zic input, so no problem either for the
Unix-world or for Java commune. Macros and shell scripts might be very
fine in Unix world but are a no-go for most Java users.
I hope that you take this into your considerations.
Am 10.02.2018 um 00:11 schrieb Paul Eggert:
> On 02/06/2018 07:40 AM, Stephen Colebourne wrote:
>> Users are encouraged to update the time-zone data themselves:
> They should continue to be able to do that. joda.org, threeten.org,
> etc. can continue to distribute tarballs in rearguard format or
> whatever other format they like, and users can use those tarballs.
> Something like this should be done regardless of whether there is any
> format change, as iana.org doesn't have the resources to support every
> device on the planet directly.
>> Since zic/make is not run, how is a downstream consumer going to use
> A process at joda.org, threeten.org, etc. can run 'make' to generate a
> tarball that contains files in rearguard format, and then joda.org,
> threeten.org etc. can redistribute that tarball. Assuming the current
> development version, the process could run something like the
> following, say.
> make rearguard.zi
> mkdir tzrear.dir
> ln rearguard.zi tzrear.dir/africa
> for file in antarctica asia australasia europe northamerica
> southamerica etcetera systemv factory backward ; do \
> touch tzrear.dir/$file || exit; \
> (cd tzrear.dir && \
> tar -cf - africa antarctica asia australasia europe
> northamerica southamerica etcetera systemv factory backward ) | \
> gzip >tzrear2018c.tar.gz
> No doubt this will require minor tweaking to pacify whatever quirks
> OpenJDK has, but I hope you get the idea.
> The point is that if OpenJDK wants a particular tweak to the format,
> then it should be in charge of its own destiny, and not be at the
> mercy of upstream changes. This is what other distributors do, and
> it's a good time for OpenJDK to start following their lead.
More information about the tz