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

[Paul G]

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

What you're effectively being asked to do is to fix the broken software that makes the inappropriate assumption that SAVE cannot be negative. He's also providing a compatibility mode for the project so that in the intermediate time it will work with broken downstream consumers, and you're being asked to redistribute the compatibility version if that's all your project can consume. Let's not be hyperbolic here, he's not asking you to maintain an entirely separate time zone database.

I'll note that this is not at *all* unheard of. Note that debian redistributes my project, python-dateutil, and applies patches to it before redistribution ( https://sources.debian.org/patches/python-dateutil/2.6.1-1/ ) so that they can use their centrally distributed zoneinfo files rather than the ones distributed with the library. Distributing software with small compatibility patches is incredibly common and probably the only sane way to manage the various different timescales on which software is developed. I don't think it's amazingly common for the upstream package to actually do the work of providing the patches *for you*, as Paul has done here.

Frankly, I'm not sure why you want to lobby so hard for this sort of thing in the upstream distribution. If you continue to rely solely on consuming the IANA data directly with no possibility to patch it if it gets out of sync with your software, you are at the mercy of the upstream distribution (as you now see). If, on the other hand, you set up your downstream software to consume patched versions of the software (even if you fix them so that the patch is no longer necessary), you can be much more responsive when something changes in an unexpected way.

On 02/11/2018 03:44 PM, Stephen Colebourne wrote:
> 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.
> 
> 
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20180211/b27e1f66/signature.asc>