[tz] Java & Rearguard

[Brian Inglis]

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-about-time

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.