[tz] zic bug: Wall-clock ordering of transition times

Tim Parenti tim at timtimeonline.com
Sat Dec 5 19:45:54 UTC 2020


I noticed a bug while incorporating changes to commentary for the Turks and
Caicos Islands…
https://mm.icann.org/pipermail/tz/2020-December/029609.html

Our contemporaneous use of "3:00" in the UNTIL field for the 2018-03-11
change intentionally avoided two clock changes in a row (first from
01:59:59 AST to 01:00:00 EST, then from 01:59:59 EST to 03:00:00 EDT an
hour later).
https://github.com/eggert/tz/commit/8792d7bed2c684cf842592fd7779645f335a33f6

My recently-added commentary clarifies the reasoning behind this and
concludes that the order was likely intended to take effect from 03:00 -04,
once the Eastern US had sprung forward, and not at 02:00 -04 as the text
suggests.

However, I noticed that using "2:00" in the UNTIL field instead doesn't
actually result in the expected extra transition:

--- to2050.tzs 2020-12-05 14:11:12.000000000 -0500
+++ to2050new.tzs 2020-12-05 14:17:31.000000000 -0500
@@ -5201,7 +5201,7 @@
 2014-03-09 03 -04 EDT 1
 2014-11-02 01 -05 EST
 2015-03-08 03 -04 AST
-2018-03-11 03 -04 EDT 1
+2018-03-11 02 -04 EDT 1
 2018-11-04 01 -05 EST
 2019-03-10 03 -04 EDT 1
 2019-11-03 01 -05 EST

It seems that, the 02:00 wall-clock time having already been approached
once for the transition out from AST, zic assumes that the transition
specified in the US Rule at the same wall-clock time has also taken
simultaneous effect in Eastern Time, although in reality it wouldn't yet
for another hour.  In this case, the wall-clock times of these two
transitions are identical, while in actuality the transitions are meant to
take effect sequentially.

It appears that this bug also manifests in other cases where the strict
ordering of transitions does not exactly match the strict ordering of
wall-clock times: Trying out "2:30" in the UNTIL field should mean that the
Zone transition should happen 30 minutes BEFORE the US Rule would take
effect (and thus require two transitions), but by wall-clock time, it would
"appear" to be 30 minutes AFTER (fooling zic into thinking only the
"latter" Zone transition is needed as the Rule would have "already" taken
effect).  And, indeed, the results are similarly incorrect here, too:

--- to2050.tzs 2020-12-05 14:11:12.000000000 -0500
+++ to2050new.tzs 2020-12-05 14:36:07.000000000 -0500
@@ -5201,7 +5201,7 @@
 2014-03-09 03 -04 EDT 1
 2014-11-02 01 -05 EST
 2015-03-08 03 -04 AST
-2018-03-11 03 -04 EDT 1
+2018-03-11 02:30 -04 EDT 1
 2018-11-04 01 -05 EST
 2019-03-10 03 -04 EDT 1
 2019-11-03 01 -05 EST

Certainly an edge case in this particular instance, but given that many
historical transitions coincide tightly with transitions in other regions
being "joined" or "left", perhaps one worth a further look.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20201205/7cd446d3/attachment.html>


More information about the tz mailing list