<div dir="ltr"><div dir="ltr"><span style="font-family:"times new roman",serif">>> I predict that significant libraries and implementations will be on rearguard forever; if that is not maintained by the TZDB, the it would be cloned and maintained externally with rearguard modifications. The cost of doing anything else would be prohibitive.</span> <br><br>My company has not been able to adapt to the new negative offsets as well and has been relying upon rearguard up to this point, given it breaks our application behavior (note C++ in our case).<div><br></div><div>The problem as I see it is around the definition of 'what is daylight saving time', and the implementation of negative DST offsets changes that definition as far as I can tell. Wikipedia describes it as such "<span style="font-family:sans-serif;font-size:14px">Daylight saving time</span><span style="font-family:sans-serif;font-size:14px"> (</span><span style="font-family:sans-serif;font-size:14px">DST</span><span style="font-family:sans-serif;font-size:14px">), also </span><span style="font-family:sans-serif;font-size:14px">daylight savings time</span><span style="font-family:sans-serif;font-size:14px"> or </span><span style="font-family:sans-serif;font-size:14px">daylight time</span><span style="font-family:sans-serif;font-size:14px"> (United States) and </span><span style="font-family:sans-serif;font-size:14px">summer time</span><span style="font-family:sans-serif;font-size:14px"> (United Kingdom, European Union, and others), is the practice of advancing clocks during summer months so that evening daylight lasts longer, while sacrificing normal sunrise times."</span> [1] <a href="http://timeanddate.com">timeanddate.com</a> describes it as "Daylight Saving Time (DST) is the practice of setting the clocks forward one hour from standard time during the summer months, and back again in the fall, in order to make better use of natural daylight." [2]. The commonality there being "advance clocks".</div><div><br></div><div>Perhaps not everyone agrees that those are reliable sources. But I think the reality is that much if not most of the software industry views them as such. So as others seem to be suggesting to me, libraries and applications have forever been written based on the definition and understand that clocks move forward with DST transitions. I know it has been said that this is a 'bad assumption', but the reality as I see it is that generally speaking all software has been written based upon what developers knew to be a 'definition' and not an 'assumption' at all.</div><div><br></div><div>So not only are we talking about incompatibilities with all the software/parsers involved with the libraries themselves (e.g. joda time), we are also talking about all software utilizing those libraries who have to account for various use cases that rely upon these "definitions".</div><div><br></div><div>As a side note, my company is highly impacted by the Brazil changes and I know it was alluded to that TZDB could perhaps use the next release to force the hand of the negative dst offset discussion (i.e. remove rearguard). I would strongly request that we not do that given the number of requests by others for an updated Brazil release as well as the amount of compatibility concerns mentioned here with negative offsets.</div><div><br></div><div>[1] <a href="https://en.wikipedia.org/wiki/Daylight_saving_time">https://en.wikipedia.org/wiki/Daylight_saving_time</a> <br>[2] <a href="https://www.timeanddate.com/time/dst/">https://www.timeanddate.com/time/dst/</a></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 30, 2019 at 8:51 AM Mark Davis ☕️ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif">> <span style="font-family:Arial,Helvetica,sans-serif">the most common (standard) time</span></div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">I predict that significant libraries and implementations will be on rearguard forever; if that is not maintained by the TZDB, the it would be cloned and maintained externally with rearguard modifications. The cost of doing anything else would be prohibitive.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">And there was really no reason whatsoever for changing policies. If we have a timezone with two separate offsets, one an hour ahead of the other, then the TZDB can chose to represent them as <0, 1> or as <-1, 0>. It is needless to have both in the database. For consistency one can simply decide to have them all be positive, which was the longstanding policy of this group until recently.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">The *name* of the time variants might use "standard" or "winter" or "lětni čas" or "夏時間", whatever is appropriate to the user's locale. There is no requirement that any two locales be aligned in what they call the "hour ahead" variant or the "hour behind" variant. The names attached to the variant by a given locale is really outside of the scope of the TZDB.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">Changing the policy to allow <-1, 0> has no particular practical benefit, and has just caused compatibility difficulties. You can't just wave a magic wand and expect longstanding APIs to return different values without causing problems for users.</div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="background-color:transparent">Mark</span></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:"times new roman",serif"><div class="gmail_default">And BTW, in most timezones around the world, a majority of the days in the year are on "daylight" time, so it is the ‘most common one’.</div></div><div><div dir="ltr" class="gmail-m_-1054605069576254186m_-2511039264815165205gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 30, 2019 at 2:04 PM Robert Elz <<a href="mailto:kre@munnari.oz.au" target="_blank">kre@munnari.oz.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Date: Thu, 30 May 2019 11:54:35 +0100<br>
From: Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>><br>
Message-ID: <<a href="mailto:CACzrW9CXTRW_G07E2Y-b2Q4%2BEw5jt8LcFSrzR-YSg0gT-0SCTw@mail.gmail.com" target="_blank">CACzrW9CXTRW_G07E2Y-b2Q4+Ew5jt8LcFSrzR-YSg0gT-0SCTw@mail.gmail.com</a>><br>
<br>
| Finally I'll note that *both* views of the data are sensible and reasonable:<br>
| - offset-focus: base/standard time in winter, advanced/daylight time<br>
| in summer (Java's choice and tzdb's old choice)<br>
<br>
tzdb never made such a choice - it simply didn't have any data that<br>
happened to have the most common (standard) time advanced ahead of<br>
the less common offset.<br>
<br>
What are you planning to do when some part of the US (say Illinois, or<br>
something else on Central time) decides to set their zone backwards by<br>
an hour for a month in the middle of winter - perhaps the winter olympics<br>
come to Denver or something, and they decide that being in the same<br>
timezone for that period has more economic and social wins than being<br>
an hour off the event times.<br>
<br>
Certainly that might be unlikely, but it certainly is not impossible,<br>
and you're not likely to get much more than a year's warning if it<br>
were to happen (at best). Wouldn't planning for this kind of thing<br>
now be much more rational than just sticking your heads in the sand<br>
with a "we didn't consider that and it is too late now" attitude.<br>
<br>
If the old APIs need to be deprecated, and a whole new set invented,<br>
then so be it - do that - the old ones can be supported, as best they<br>
can be given they are based upon false assumptions, for a long time,<br>
but averything should be encouraged to convert to something rational,<br>
with no in-built assumptions about what is possible or rational wrt<br>
local time.<br>
<br>
| - legal-focus: follow government law as to the meaning of<br>
| standard/daylight (tzdb's new choice)<br>
<br>
First, standard time is the time that applies *now* - whenever now is.<br>
If it has a name, distinct from the name that applies to the time at<br>
some other time of the year, that's fine (but almost irrelevant to<br>
anything).<br>
<br>
| Most Java libraries aren't going to change because doing so would<br>
| impact compatibility in APIs.The real problem here is how tricky it is<br>
| to reverse engineer the old data from the new data.<br>
<br>
I suspect that the real problem is that the current APIs are simply<br>
inadequate to describe real world time behaviour. Any assumptions<br>
made, anywhere, about almost anything, will almost guarantee that.<br>
<br>
kre<br>
<br>
</blockquote></div>
</blockquote></div>