[tz] [PROPOSED] Support zi parsers that mishandle negative DST offsets

[Stephen Colebourne]

On 9 February 2018 at 23:11, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> 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.

To be clear here, as the maintainer of the project, you are
effectively asking some of its key consumers to fork the project. I
find that pretty astonishing.

The tzdb project has provided a distribution of the relevant data in a
suitable form for consumption for 20 years or so. It still does today,
as the change is currently rolled back.

I'm certainly not about to go replicating the tzdb distribution,
placing large amount of work and cost on me, merely to work around a
change that simply should not be happening. Mark Davis has recently
expressed this again in another thread - there is absolutely no good
rationale for making this change, and it clearly causes major pain.
The only effect on zic is a flag that everyone seems to agree is
pointless/deprecated, and some disagree that the change is correct wrt
the flag's specification. A rational observer would be astonished that
this issue got beyond 20 emails never mind 200.

If zic wants to reverse the dst flag, it should do so. The source
files should remain with positive SAVE values.

Stephen


> 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.