Bug in tz code

John Dlugosz JDlugosz at TradeStation.com
Thu Jan 22 20:58:44 UTC 2009


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.

 

--John

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20090122/5e4a580d/attachment-0001.html 


More information about the tz mailing list