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

Brian Park brian at xparks.net
Mon Jan 4 18:35:08 UTC 2021


On Thu, Dec 31, 2020 at 1:14 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/31/20 11:22 AM, Brian Park wrote:
> > The thing that I was wondering was whether the semantics of the zone info
> > text files actually mandated a transition from 2:00 to 1:00 for
> Grand_Turk,
> > if the Zone entry was set to 2:00, instead of its current 3:00 value. Or
> > whether the special case in the zic compiler was an additional rule on
> top
> > of the normal semantics of the zone info text files, in order to parse
> the
> > Grand_Turk case properly.
>
> The latter. That is, original semantics would have required two
> transitions there, but when this sort of problem was discovered in the
> mid-1990s the zic behavior was changed by adding the special case.
> Unfortunately, this special case wasn't documented in the zic man page
> until recently.
>
> The recent doc change is here:
>
>
> https://github.com/eggert/tz/commit/b804a741d5cdb5d1b761de9ad053ba916fa08636
>
> and you can see a recent message about this here:
>
> https://mm.icann.org/pipermail/tz/2020-December/029616.html


Yup, I did read those messages, and the 1996 emails too. I am still
confused why the normal semantics require 2 transitions. Could you be kind
enough to explain? Because I implemented my code before I knew about the
special code in zic(1) to handle this case. My code produces only one
transition for Grand_Turk at 2:00, and one transition for the original
Atlantic/Stanley zone at 00:00 on Sept 15 1985, as referenced in the 1996
email thread.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210104/1b62cbe5/attachment.html>


More information about the tz mailing list