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