[tz] Irish Standard Time vs Irish Summer Time
Mark Davis ☕️
mark at macchiato.com
Sun Jan 21 02:04:19 UTC 2018
I don't think that a compelling reason has been me for this change in the
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...
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
> (it works just fine), nor with libraries that use the binary output of zic
> far, no problems have been reported for them, and this makes sense if you
> at the format of the binary data), nor even with applications that use
> libraries (so far, just one quite-minor and easily-fixed problem has been
> reported, and it was reported only because I looked carefully through
> the most tzcode-intensive application on the planet).
> No, the main problem with negative DST offsets appears to lie in other
> consumers, which assume that DST offsets must be positive. Until 2018a the
> man page did not document that negative DST offsets were allowed in zic
> and developers of some other software missed the possibility of negative
> offsets even though tzcode has supported them for decades.
> We've run into similar problems in the past with tzcode directly. That is,
> changed tzcode to extend the format of zic input, and then we've waited a
> before using these extensions in tzdata. This wait gave downstream
> time to upgrade their zic implementations to add support for these
> Given that negative DST wasn't clearly documented until 2018a, I also
> that we extend a sizable grace period to downstream code, as it will take
> time for people to update that code and get updated versions into
> During that transition period, we can provide options so that downstream
> can use the full data, or a bowdlerized version of the data that avoids
> 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...
More information about the tz