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

[Brian Park]

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

Regards,
Brian




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