[tz] Java & Rearguard

[Robert Elz]

    Date:        Thu, 30 May 2019 11:54:35 +0100
    From:        Stephen Colebourne <scolebourne at joda.org>
    Message-ID:  <CACzrW9CXTRW_G07E2Y-b2Q4+Ew5jt8LcFSrzR-YSg0gT-0SCTw at mail.gmail.com>

  | 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.

kre