[tz] Irish Standard Time vs Irish Summer Time

[Mark Davis ☕️]

I don't think that a compelling reason has been me for this change in the
first place.

No matter what the 'transition' period is, why do we need to do any of
this? Why upset a huge number of older implementations?

The reason has to be pretty darned important...

{phone}

On Sat, Jan 20, 2018, 17:51 Paul Eggert <eggert at cs.ucla.edu> wrote:

> John Hawkinson wrote:
> > in the world of timezone software, with complex downstream dependencies
> and embedded devices and mobile devices with weird update strategies that
> take data but not code, a year is *not* a long period of time. It's not
> long for tzdata, but it is far shorter for code.
>
> As I understand it, the important problem with negative DST lies not in
> tzcode
> (it works just fine), nor with libraries that use the binary output of zic
> (so
> far, no problems have been reported for them, and this makes sense if you
> look
> at the format of the binary data), nor even with applications that use
> those
> libraries (so far, just one quite-minor and easily-fixed problem has been
> reported, and it was reported only because I looked carefully through
> perhaps
> the most tzcode-intensive application on the planet).
>
> No, the main problem with negative DST offsets appears to lie in other
> tzdata
> consumers, which assume that DST offsets must be positive. Until 2018a the
> zic
> man page did not document that negative DST offsets were allowed in zic
> input,
> and developers of some other software missed the possibility of negative
> DST
> offsets even though tzcode has supported them for decades.
>
> We've run into similar problems in the past with tzcode directly. That is,
> we've
> changed tzcode to extend the format of zic input, and then we've waited a
> while
> before using these extensions in tzdata. This wait gave downstream
> developers
> time to upgrade their zic implementations to add support for these
> extensions.
>
> Given that negative DST wasn't clearly documented until 2018a, I also
> suggest
> that we extend a sizable grace period to downstream code, as it will take
> some
> time for people to update that code and get updated versions into
> production.
> During that transition period, we can provide options so that downstream
> users
> can use the full data, or a bowdlerized version of the data that avoids
> negative
> DST but is otherwise as close to the original as is practical. This can
> all wait
> until after 2018c is announced.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180121/5d643174/attachment-0001.html>