[tz] Java & Rearguard

[Robert Elz]

    Date:        Sat, 1 Jun 2019 00:43:57 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <b75be6cf-e270-27be-f647-020cf5dd456d at cs.ucla.edu>

  | Brandon Smith wrote:
  |
  | > we now have a situation in which the transition from DST off to DST on
  | > results in an ambiguous local time period for Ireland.
  |
  | For what it's worth, this particular situation is not new in tzdata. For 
  | example, Europe/Kiev has a transition from +03 (without DST) to +02
  | (with DST) on 1941-09-19 at 24:00,

It could be worse than that ... imagine that Lilliput (which is UTC+N) decides
that it really ought to be in the same timezone as Brobdingnag (which is UTC+M)
where (just like in ascii) N = M + 1.   (And because O is kind of hard to
distinguish from 0, we'll make P = N + 1).

The way they decide to make the conversion, is that when their summer time
ends, instead of changing from LDT (UTC+P) to LST (UTC+N) they're going to
change from LDT (UTC+P) to BDT (UTC+N) (the same change, with a different
name) and then when Brobdingnag's summer time ends, they'll switch
from BDT (UTC+N) to BST (UTC+M).

Now it happens that both Lilliput and Brobdingnag end summer time at 03:00
(local summer time) on the first Sunday in Gullivmon (they have both named a
month after a prominent local citizen).

So, at 03:00 (LDT) this year on Gul the 3rd, the clocks in Lilliput will be
switched from showing 03:00 LDT to 02:00 BDT, and then at 03:00 (BDT) this
year on Gul the 3rd, the clocks in Lilliput will be switched from showing
03:00 BDT to 02:00 BST.   At 03:00 BST nothing notable happens...

Almost nothing is beyond comprehension when it comes to local time
representations.   Making any assumptions at all about how things
work is guaranteed to fail sometime.

What's more, this scenario defeats the one plausible application use
of tm_isdst that exists - that is, setting it to 0 or 1 to indicate
that when one says "02:30:00 3-Gul-wxyz" which time is intentended
when that is broken down into tm_* fields and handed to mktime() as
now there are 3 possible UTC timestamps that could be picked, rather
than the normal two in ambiguous situations.

It also all depends upon the exact sematics - the clocks would have
behaved identically, but the results should be different, had Lilliput
decided to switch to BST at the same time as Brobdingnag switched from
BDT to BST.  Just before that they would have done their normal switch
from LDT to LST.   Either way though there's an ampbguous time where the
value of (an output) tm_isdst (and all other tm_* fields, except tm_gmtoff
and tm_zone in implementations that have them) are identical in the
output from localtime() given two different time_t inputs.

kre

ps: aside from mktime() not really being able to work sensibly, as its
API is inadequate, tzdb supports all of this kind of thing.