[tz] Irish Standard Time vs Irish Summer Time

[Paul G]

I think it's fine to roll back this cosmetic change - particularly if there's still ongoing discussion as to whether it is or is not going to be included in the end (about which I am ambivalent) - but if the change *is* coming, I don't think waiting a year to release the new version is the right thing to do. The problem is that, as we have found out with this release, even people with year-long lead times don't seem to bother testing against anything except the release version of the database. I think what is likely to happen is 2018c comes out reverting this change, all the alarms stop going off when 2018c is updated, and the common wisdom is "don't use 2018a or 2018b", then when 2019a comes out the same problem happens again.

It seems to me like the right thing to do would be to cut a 2018c release, figure out whether negative SAVE is worth the hassle and if it's decided that negative SAVE values *are* valid, then a new release should be cut maybe 1 month afterwards that has the negative SAVE values. Broken compilers with a long release cycle should probably just create their own distribution channel for a patched version of zoneinfo that maintains their erroneous assumptions about the code until a fix is released.

Another alternative might be to create a "testzone" file containing test zones that deliberately violate various assumptions that downstream consumers may have made but which are *not* intended to be stable features of the data, and could include a zone that contains negative SAVE. Then upstream the negative SAVE can be delayed a year in the Europe/Dublin zone and downstream consumers can skip testzone in production builds.

I personally prefer the first approach - the tzdata should not be slowed down to the release cycle of the slowest consumer of the data. This change will have to permeate through a lot of software that *indirectly* uses these zonefiles (and it's not terribly reasonable to test against dev builds of all your direct *and indirect* dependencies), so waiting a year before it gets through the first-level consumers means this process could be drawn out interminably.

Best,

Paul

On 01/19/2018 12:44 AM, Philip Paeps wrote:
> On 2018-01-18 19:39:50 (-0500), Tom Lane wrote:
>> Zefram <zefram at fysh.org> writes:
>>> There was indeed a significant chance of the negative SAVE value breaking alternate zic implementations, and now that that's turned out to be the case that's good cause to postpone this correction, or at least the expressing of it in this natural manner.  The tzdb does have unusually high stability requirements.  But that's not a reason to keep the database forever inaccurate.
>>
>> I'm not sure that it's "inaccurate".  The question is more about what is the meaning of tm_isdst = 1.  It's clear from this discussion that an awful lot of code believes it means "local time is advanced now compared to what it is when tm_isdst = 0".  Arguing that it should reflect a legalistic definition of DST, rather than an operational definition, is just an argument; it's not conclusive.
>>
>> FWIW, I share the opinion that this change was misguided.
> 
> I'd go with "premature" rather than "misguided".
> 
> Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
> 
> Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
> 
> Philip
> 

-------------- 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/20180119/49587646/signature.asc>