[tz] [english 99%] Re: [PROPOSED] Support zi parsers that mishandle negative DSToffsets

[Meno Hochschild]

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.

Meno

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:
>> http://www.joda.org/joda-time/tz_update.html
>> http://www.threeten.org/threetenbp/update-tzdb.html
>>
> 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 
>> them
> 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; \
>     done
> (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.
>