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. --ado From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Thursday, January 22, 2009 3:59 To: tz@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. --John
The America/Godthab problem is a fencepost error; the proposed change below fixes it. --ado ------- zic.c ------- *** /tmp/geta5564 Mon Jan 26 16:26:50 2009 --- /tmp/getb5564 Mon Jan 26 16:26:50 2009 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.18"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.19"; #include "private.h" #include "locale.h" *************** *** 1995,2001 **** min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i]; --- 1995,2001 ---- min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear + (leapmaxyear < INT_MAX)); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i];
As expected, your change affects the following zones, for dates after the spring of 2475 for: Africa/Cairo America/Godthab Antarctica/Palmer A quick check indicates the expected fix, following DST rules into the future. And I'm also getting different output for only times between 2009-12-30T20:00:00 and 2009-12-31T20:00:00 (local time) for America/Eirunepe, which is strange. --John -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Monday, January 26, 2009 3:34 PM To: tz@elsie.nci.nih.gov Cc: John Dlugosz Subject: RE: Bug in tz code The America/Godthab problem is a fencepost error; the proposed change below fixes it. --ado ------- zic.c ------- *** /tmp/geta5564 Mon Jan 26 16:26:50 2009 --- /tmp/getb5564 Mon Jan 26 16:26:50 2009 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.18"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.19"; #include "private.h" #include "locale.h" *************** *** 1995,2001 **** min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i]; --- 1995,2001 ---- min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear + (leapmaxyear < INT_MAX)); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i];
(But, why didn't [zic] just generate a POSIX rule string [for America/Godthab] like most of the files?)
POSIX time zone strings always use local time. Godthab transitions occur at 1:00 UCT on the last Sunday of March or October, at which point it's Saturday in Godthab. So Godthab transitions occur between the 24th and the 30th of the month--a range which can't be represented with a POSIX string (in which week 4 covers 22-28 and week 5 covers 25-31). --ado
participants (2)
-
John Dlugosz -
Olson, Arthur David (NIH/NCI) [E]