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