RE: compile errors on timezone database
Back in 1998 zic was tweaked to accept 24:00 in "AT" fields; my guess is that the version of zic being used predates that change. (If the vendor hasn't stripped things and you're on a POSIX system, you can do a... what /path/to/the/executable/zic ...to get a version number; anything under 7.94 lacks the tweak; anything beyond 7.95 has the tweak.) Mindful of folks with old compilers, it may be best to change the northamerica file to avoid use of 24:00, changing the "lastSat 24:00" references to "lastSun 0:00". (And perhaps using zic should generate warning messages if a 24:00 shows up and zic's -v option has been used.) --ado -----Original Message----- From: Diane Kledzik [mailto:Diane_Kledzik@notes.ntrs.com] Sent: Tuesday, December 02, 2003 12:52 PM To: tz@lecserver.nci.nih.gov Cc: eggert@twinsun.com Subject: compile errors on timezone database As an fyi, I receive compile errors when I compile (using "zic") the time zone database downloaded in the tzdata2003d.tar file from your ftp://elsie.nci.nih.gov/pub/ site. The error messages read: "northamerica", line 954: invalid time of day "northamerica", line 955: invalid time of day "northamerica", line 978: invalid time of day "northamerica", line 979: invalid time of day Those lines in the northamerica file are below. Is it safe to assume I need to change the 24:00 references to 0:00 instead? Has anyone else run into this problem? Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Thanks for your help, Diane Kledzik
On Tue, 2 Dec 2003, Olson, Arthur David (NIH/NCI) wrote:
Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S
Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S
Mindful of folks with old compilers, it may be best to change the northamerica file to avoid use of 24:00, changing the "lastSat 24:00" references to "lastSun 0:00".
This would not be correct. For example, in 1932, the last Saturday in April was April 30, 1932 so the change to DST happened that night. Changing the entry to "lastSun 0:00" would cause the change to DST in 1932 to take place on Sunday, April 24, 1932 -- a week too early. Ephraim ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-6757244 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim@cse.huji.ac.il
The rules "LastSat 24:00" and "LastSun 0:00" may not always be equivalent, although I don't know if the specific programming is taking care of that. But I suspect not. Consider September 1933, which is within the range of the mentioned rules. Last Saturday of September is the 30.th. of September, so "LastSat 24:00" would change exactly going into Sunday October 1.st. at 0:00. However, "LastSun 0:00" would be September 24.th. at 0:00 or exactly one week before. This really occurs because Sunday October 1.st. is not part of September. I had a similar problem with my definition of a Greenland timezone, which had the effect that it took place one week from when it should. I don't know if this actually is calculated like this with the tz package. I just want to point out the conceptual problem, for your afterthought. Regards, Jesper Nørgaard Welen -----Original Message----- From: Olson, Arthur David (NIH/NCI) [mailto:olsona@dc37a.nci.nih.gov] Sent: 2. december 2003 15:17 To: Tz (tz@elsie.nci.nih.gov); 'diane_kledzik@notes.ntrs.com' Subject: RE: compile errors on timezone database Back in 1998 zic was tweaked to accept 24:00 in "AT" fields; my guess is that the version of zic being used predates that change. (If the vendor hasn't stripped things and you're on a POSIX system, you can do a... what /path/to/the/executable/zic ...to get a version number; anything under 7.94 lacks the tweak; anything beyond 7.95 has the tweak.) Mindful of folks with old compilers, it may be best to change the northamerica file to avoid use of 24:00, changing the "lastSat 24:00" references to "lastSun 0:00". (And perhaps using zic should generate warning messages if a 24:00 shows up and zic's -v option has been used.) --ado -----Original Message----- From: Diane Kledzik [mailto:Diane_Kledzik@notes.ntrs.com] Sent: Tuesday, December 02, 2003 12:52 PM To: tz@lecserver.nci.nih.gov Cc: eggert@twinsun.com Subject: compile errors on timezone database As an fyi, I receive compile errors when I compile (using "zic") the time zone database downloaded in the tzdata2003d.tar file from your ftp://elsie.nci.nih.gov/pub/ site. The error messages read: "northamerica", line 954: invalid time of day "northamerica", line 955: invalid time of day "northamerica", line 978: invalid time of day "northamerica", line 979: invalid time of day Those lines in the northamerica file are below. Is it safe to assume I need to change the 24:00 references to 0:00 instead? Has anyone else run into this problem? Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Thanks for your help, Diane Kledzik
Olson, Arthur David (NIH/NCI) wrote:
Back in 1998 zic was tweaked to accept 24:00 in "AT" fields; my guess is that the version of zic being used predates that change. (If the vendor hasn't stripped things and you're on a POSIX system, you can do a... what /path/to/the/executable/zic ...to get a version number; anything under 7.94 lacks the tweak; anything beyond 7.95 has the tweak.)
Mindful of folks with old compilers, it may be best to change the northamerica file to avoid use of 24:00, changing the "lastSat 24:00" references to "lastSun 0:00". (And perhaps using zic should generate warning messages if a 24:00 shows up and zic's -v option has been used.)
Because of the lastSat-might-be-the-last-day-of-the-month issue the Right Thing to be done is to update zic and use the correct zoneinfo definition. Rodrigo Severo -- ---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ----------------------------------------------------
participants (4)
-
Ephraim Silverberg -
Jesper Norgaard Welen -
Olson, Arthur David (NIH/NCI) -
Rodrigo Severo