FW: Bug in tz code
Olson, Arthur David (NIH/NCI) [E]
olsona at dc37a.nci.nih.gov
Thu Jan 22 21:45:55 UTC 2009
I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
From: John Dlugosz [mailto:JDlugosz at TradeStation.com]
Sent: Thursday, January 22, 2009 3:59
To: tz at lecserver.nci.nih.gov
Subject: Bug in tz code
The file America/Godthab, for whatever reason, does not have a POSIX rule string at the end of it. It does have 859 transition times, so far future dates rely on the cyclic behavior of the calendar.
However, upon loading, the code does not set the 'goforward' flag. So, in the future (around the year 2409) it does not cycle but uses the last setting indefinitely (WGT) and stops going into daylight savings time (WGST).
It was *supposed* to set 'goforward'. But, it did not work. The last entry in ats is 13847763624. So, differ_by_repeat will look for an entry of 1224982824. What is actually in the file is an entry of 1224982823, which is one second too soon to be what is being sought.
It broke because differ_by_repeat does not consider leap seconds. The addition of a leap second at the end of 2008 broke it. In order to work properly, zic needs to generate 400 years of table after the last leap second that it used.
(But, why didn't it just generate a POSIX rule string like most of the files?)
It looks like America/Santiago has the same problem. This might affect all the files that are overly large, and perhaps the lack of POSIX string (and large number of transition times instead) is related to the same issue.
More information about the tz