<div dir="auto">I don't think that a compelling reason has been me for this change in the first place. <div dir="auto"><br></div><div dir="auto">No matter what the 'transition' period is, why do we need to do any of this? Why upset a huge number of older implementations?</div><div dir="auto"><br></div><div dir="auto">The reason has to be pretty darned important...</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">{phone}</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 20, 2018, 17:51 Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John Hawkinson wrote:<br>
> 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.<br>
<br>
As I understand it, the important problem with negative DST lies not in tzcode<br>
(it works just fine), nor with libraries that use the binary output of zic (so<br>
far, no problems have been reported for them, and this makes sense if you look<br>
at the format of the binary data), nor even with applications that use those<br>
libraries (so far, just one quite-minor and easily-fixed problem has been<br>
reported, and it was reported only because I looked carefully through perhaps<br>
the most tzcode-intensive application on the planet).<br>
<br>
No, the main problem with negative DST offsets appears to lie in other tzdata<br>
consumers, which assume that DST offsets must be positive. Until 2018a the zic<br>
man page did not document that negative DST offsets were allowed in zic input,<br>
and developers of some other software missed the possibility of negative DST<br>
offsets even though tzcode has supported them for decades.<br>
<br>
We've run into similar problems in the past with tzcode directly. That is, we've<br>
changed tzcode to extend the format of zic input, and then we've waited a while<br>
before using these extensions in tzdata. This wait gave downstream developers<br>
time to upgrade their zic implementations to add support for these extensions.<br>
<br>
Given that negative DST wasn't clearly documented until 2018a, I also suggest<br>
that we extend a sizable grace period to downstream code, as it will take some<br>
time for people to update that code and get updated versions into production.<br>
During that transition period, we can provide options so that downstream users<br>
can use the full data, or a bowdlerized version of the data that avoids negative<br>
DST but is otherwise as close to the original as is practical. This can all wait<br>
until after 2018c is announced.<br>
</blockquote></div>