On 2019-05-30 08:26, Brandon Smith wrote:
On Thu, May 30, 2019 at 8:51 AM Mark Davis ☕️ wrote:
On Thu, May 30, 2019 at 2:04 PM Robert Elz wrote:
On Thu, 30 May 2019 11:54:35 +0100, Stephen Colebourne wrote: the most common (standard) time 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.
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.
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.
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.
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’.
| Finally I'll note that *both* views of the data are sensible and reasonable: | - offset-focus: base/standard time in winter, advanced/daylight time | in summer (Java's choice and tzdb's old choice)
tzdb never made such a choice - it simply didn't have any data that happened to have the most common (standard) time advanced ahead of the less common offset.
What are you planning to do when some part of the US (say Illinois, or something else on Central time) decides to set their zone backwards by an hour for a month in the middle of winter - perhaps the winter olympics come to Denver or something, and they decide that being in the same timezone for that period has more economic and social wins than being an hour off the event times.
Certainly that might be unlikely, but it certainly is not impossible, and you're not likely to get much more than a year's warning if it were to happen (at best). Wouldn't planning for this kind of thing now be much more rational than just sticking your heads in the sand with a "we didn't consider that and it is too late now" attitude.
If the old APIs need to be deprecated, and a whole new set invented, then so be it - do that - the old ones can be supported, as best they can be given they are based upon false assumptions, for a long time, but averything should be encouraged to convert to something rational, with no in-built assumptions about what is possible or rational wrt local time.
| - legal-focus: follow government law as to the meaning of | standard/daylight (tzdb's new choice)
First, standard time is the time that applies *now* - whenever now is. If it has a name, distinct from the name that applies to the time at some other time of the year, that's fine (but almost irrelevant to anything).
| Most Java libraries aren't going to change because doing so would | impact compatibility in APIs.The real problem here is how tricky it is | to reverse engineer the old data from the new data.
I suspect that the real problem is that the current APIs are simply inadequate to describe real world time behaviour. Any assumptions made, anywhere, about almost anything, will almost guarantee that.
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.
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).
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 "Daylight saving time (DST), also daylight savings time or daylight time (United States) and summer time (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." [1] timeanddate.com <http://timeanddate.com> 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".
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.
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".
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.
Interesting points of view about your own problems but kind of missing the point about the *volunteer* maintainer's scope of maintaining the data, the tools, and the API to use the data, as intended, in their own *personal free time*. None of these complaints are from users of the data and code base, but third party users, including some commercial projects and companies, who appear to have caused problems by allowing access to low level details of the implementation. A lesson that should have been learned and remembered from twenty years ago, is that date/time/duration data must be opaque to apps and programmers, and they must use a high level API on it, otherwise one is no better off than using the low level C API. AFAICT tz db has always set up its rules to match whatever each government decrees: if that happens to be in a non Gregorian calendar - Hebrew or Muslim - the maintainers have used some calendar conversions to generate those dates for future years, as best they can predict, as with anything politically based. Now for their usual political reasons some governments are being different and instead of using standard and advanced summer times, they are using winter and advanced standard/summer times, negative standard offsets, 24-25 hour times, etc. Some people, possibly some managers in commercial orgs, are now complaining their apps won't work with the canonical data, because their organizations designed or implemented their applications with limitations, because they *chose not to use the canonical data, tools, or API*, or take the time to understand enough about time, politics, design, and programming, despite the myriads of articles and posts about such mistaken beliefs: Falsehoods "Programmers" Believe About <TOPIC>; see: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-abo... and all the related links to more falsehoods about time and other real life topics. One of those mistaken beliefs is that fixing these problems takes a lot of effort and costs a lot of money: I've heard people I work with and for make these kinds of statements without any basis except a "chicken little" attitude, and corrected them. Handling these kinds of changes is just part of the job, and if designs or code have to change, they were deficient or defective in the first place, so maybe have your best programmers look at your code base, count how many lines of code are affected by these fixes, how many minutes it will take to make the changes, and how much money that costs. If the answer is too much, you have a *much* bigger problem! The maintainer spent a few hours of his own personal free time coming up with and implementing rearguard format and making all the data changes required to accommodate legacy apps. There was no requirement to do so but he saw a real issue, mistakenly expecting those others to do their jobs and upgrade their apps to remove their limitations. It should only take others a few hours to make similar accomodations to upgrade their apps and remove their limitations. Those paid to support and maintain those legacy apps by their orgs now have an opportunity to do their jobs, a year later, by *choosing* getting those apps updated so they can continue to take advantage of the resources provided. Alternately, they can *choose* to pay their staff to maintain a version of the data compatible with their app, until another political change comes along to break it and force a change. The primary goal of the project should be to maintain the data, tools, and API for using the data. Third party, especially commercial, software should not be a major consideration, especially if they choose not to use the supported API, as they should have the resources to deal with any issues arising from *their choices*. Providing time for a transition or an interim data format during transition is being considerate over and above the required scope. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.