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

Brian Park brian at xparks.net
Tue Dec 29 19:08:05 UTC 2020

(+howard.hinnant at gmail.com, for reference to his
https://github.com/HowardHinnant/date library below)

Hello folks,

I maintain my own TZ database parser and compiler for one of my projects. I
run automatic validation tests against Howard's date library, so I was
curious about how my TZ parser and Howard's parser handle this 2:00 versus
the 3:00 UNTIL time for America/Grand_Turk. The summary is that both of
them handle the 2:00 UNTIL time just fine.

I did not write any special case for Grand_Turk in my parser, so I was
curious to know why it just worked, just in case it worked only
"accidentally". It took me some time to understand my own code, since I
cannot keep all of its parsing logic in my head for more than a few weeks
at a time. The core of why it "just works" seems be in the interpretation
of the "2:00 transition to US Rule", and the fact that "2:00" is Wall-time,
not S-time or U-time:

So, on Mar 11, 2018:

* At 1:59, Grand_Turk is on UTC-4. It does not know about Eastern Time, nor
does it care.
* At 2:00, Grand_Turk switches to UTC-5, and starts using US Rules. One of
those US rules says, at 2:00 *wall time*, use SAVE +1.
* Grand_Turk says, ok, I used to be on UTC-4. Now the rules say that I
should be UTC-5+1 (i.e. UTC-4), so I'll just keep using UTC-4. The wall
clock goes from 1:59, to 2:00, then 2:01, ..., 2:59, then finally to 3:00.
* Grand_Turk only cares about transition rules and UTC offsets. It does not
know about Eastern Time, so it does not change 2:00 to 1:00.
* The time interval 2:00-3:00 does not exist for clocks on Eastern Time.
But Grand_Turk is not using an Eastern clock, it's using its own clock, and
2:00-3:00 *does* exist for Grand_Turk.

Anyway, that's my simple human translation of what my code does for this
case. The actual logic, just like zic.c, is far more complicated than can
be explained in words. I am not familiar with the details of what Howard's
date library does internally, but I'm always happy to be in agreement with
his library.


On Mon, Dec 7, 2020 at 5:25 PM Arthur David Olson <
arthurdavidolson at gmail.com> wrote:

> > Good memory!
> I wish. In this case, though, grep and a comprehensive text file of time
> zone electronic mail sufficed.-)
>     --ado
> On Mon, Dec 7, 2020 at 8:13 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
>> On 12/7/20 1:29 PM, Arthur David Olson wrote:
>> > https://mm.icann.org/pipermail/tz/1996-May/date.html
>> > <https://mm.icann.org/pipermail/tz/1996-May/date.html>
>> > ...includes links to messages regarding the work done in 1996; check
>> out the
>> > messages including "simultaneous" in the subject.
>> Thanks for the pointers. So it's a bit of code that you and I wrote, and
>> that
>> I'd totally forgotten about. Good memory!
>> For the record, the commit in question is dated 1996-05-16 13:48:28 -04
>> and can
>> be found here:
>> https://github.com/eggert/tz/commit/2f53da99b5fb6e0a4cf5861ed80d84643032aeec
>> and it says (in C) roughly what I attempted to write (in longer English)
>> in the
>> recent doc patch. Admittedly a bit of a delay between installing the code
>> and
>> installing the corresponding documentation....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20201229/c597e1c2/attachment.htm>

More information about the tz mailing list