- tz - lists.iana.org

FW: Pacific-New
by Olson, Arthur David (NIH/NCI) [E] Feb. 25, 2009

Feb. 25, 2009

I'm forwarding this message from Bill Unruh, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Bill Unruh [mailto:unruh@physics.ubc.ca] Sent: Sunday, February 22, 2009 6:35 To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)lecserver.nci.nih.gov Subject: RE: Pacific-New On Sun, 22 Feb 2009, Olson, Arthur David (NIH/NCI) [E] wrote: > The "pacificnew" file includes information about legislation that was > introduced (but not passed) in the United States Congress; it serves to > explain why a "Pacific-New" time zone was created in the first place. > Note that the last line of the file is a "Link America/Los_Angeles > US/Pacific-New" line, meaning that using either name now has the same > effect. I guess I object strongly to including legislative proposals into the tzdata files. If we introduce a new file and a new timezone everytime some government official makes some silly comment about time, the whole edifice will collapse under the weight of that garbage. While the tzdata file is not an official publication it is regarded as pretty authoritiative by most people using computers in the world. It should therefore strive to be accurate and authoritative, and not get bogged down with irrelevancies, and political commentary or jokes (which is the only thing I can imagine that the Pacific-New timezone to be). > > As to jokes and idiocy: there used to be an obscure bit of word play in > an strftime.c comment; > it was eliminated in version 7.40.-) Never saw it. I am not above jokes and wordplay but not when it extends to introducing new time zones in at least semi-authoritative publications. Are we going to get an Okeefenokie time zone because someone likes Pogo-- or a US/BUSH timezone (constantly set to midnight) as political commentary on the last president? That an ill-considered proposal popped up in Congress 20 years ago but was never passed should not be memorialised by a new time zone in tzdata. My response was triggered when a Suse user said his distro assigned Pacific-New to him. Having never seen it before (Mandriva wisely does not have it), I looked at the tzdata file and found it. Please please remove it. > > --ado > -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | unruh(a)physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

5 5

FW: Pacific-New
by Olson, Arthur David (NIH/NCI) [E] Feb. 22, 2009

Feb. 22, 2009

I'm forwarding this message from Bill Unruh, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Bill Unruh [mailto:unruh@physics.ubc.ca] Sent: Sunday, February 22, 2009 3:18 To: tz(a)lecserver.nci.nih.gov Subject: Pacific-New Why in the world do you have that joke of a file pacificnew included in the tzdata database? It is a completely stupid joke, or political protest against yet another idiotic bill passed by the House, but never made it anywhere near law. People are actually using Pacific-New as a time zone in various distributions of Linux. tzdata is supposed to be a somewhat authoritative site for time zone info, and not a place for sophmoric jokes or political protest. It makes one think that the rest of your database may be similarly infused with idiocy. Are we going to find new files with protests against Islamic law, or Communist propeganda infiltrating the database next? -- William G. Unruh Canadian Institute for Tel: +1(604)822-3273 Physics&Astronomy Advanced Research Fax: +1(604)822-5324 UBC, Vancouver,BC Program in Cosmology unruh(a)physics.ubc.ca Canada V6T 1Z1 and Gravity http://axion.physics.ubc.ca/ For step by step instructions about setting up ppp under Linux, see http://axion.physics.ubc.ca/ppp-linux.html

2 2

Pacific-New
by Bill Unruh Feb. 22, 2009

Feb. 22, 2009

Why in the world do you have that joke of a file pacificnew included in the tzdata database? It is a completely stupid joke, or political protest against yet another idiotic bill passed by the House, but never made it anywhere near law. People are actually using Pacific-New as a time zone in various distributions of Linux. tzdata is supposed to be a somewhat authoritative site for time zone info, and not a place for sophmoric jokes or political protest. It makes one think that the rest of your database may be similarly infused with idiocy. Are we going to find new files with protests against Islamic law, or Communist propeganda infiltrating the database next? -- William G. Unruh Canadian Institute for Tel: +1(604)822-3273 Physics&Astronomy Advanced Research Fax: +1(604)822-5324 UBC, Vancouver,BC Program in Cosmology unruh(a)physics.ubc.ca Canada V6T 1Z1 and Gravity http://axion.physics.ubc.ca/ For step by step instructions about setting up ppp under Linux, see http://axion.physics.ubc.ca/ppp-linux.html

1 0

Why is there not a Asia/Beijing timezone?
by Matthew Young Feb. 14, 2009

Feb. 14, 2009

The standard time in China is Beijing time. Why is there no Beijing timezone in your database? Microsoft Windows has a Beijing time zone.

1 0

FW: Entry For Europe/Athens
by Olson, Arthur David (NIH/NCI) [E] Feb. 13, 2009

Feb. 13, 2009

I'm forwarding this message from Luke, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Luke [mailto:spizzer@gmail.com] Sent: Friday, February 13, 2009 3:10 To: tz(a)lecserver.nci.nih.gov Subject: Entry For Europe/Athens Hi, I've been working on a issue with Geosetter which uses your timeinfo database. Please see http://www.geosetter.de/mantis/view.php?id=572 for some more history. This is for Europe 8.20, but Geosetter ships with 8.12. >From this point on we are talking about 8.20 Lines 1212 to 1218 inclusive. FROM Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks & Pottenger say it switched to C-Eur in 1981; # go with EU instead, since Greece joined it on Jan 1. 2:00 EU EE%sT TO Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 2:00 EU EE%sT I'm not sure where the problem lies? Maybe Geosetter can not handle the # out lines within the rules. Regards, Luke

1 0

Entry For Europe/Athens
by Luke Feb. 13, 2009

Feb. 13, 2009

Hi, I've been working on a issue with Geosetter which uses your timeinfo database. Please see http://www.geosetter.de/mantis/view.php?id=572 for some more history. This is for Europe 8.20, but Geosetter ships with 8.12. >From this point on we are talking about 8.20 Lines 1212 to 1218 inclusive. *FROM* Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks & Pottenger say it switched to C-Eur in 1981; # go with EU instead, since Greece joined it on Jan 1. 2:00 EU EE%sT *TO* Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 2:00 EU EE%sT I'm not sure where the problem lies? Maybe Geosetter can not handle the # out lines within the rules. Regards, Luke

1 0

tzcode2009b.tar.gz and tzdata2009b.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Feb. 9, 2009

Feb. 9, 2009

The files... ftp://elsie.nci.nih.gov/pub/tzcode2009b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2009b.tar.gz ...are now available; these reflect the changes circulated last week on the time zone mailing list. --ado

1 0

Coordinates format
by Jonas Melian Feb. 3, 2009

Feb. 3, 2009

Hi, I've seen that is used the format "+-DDMM+-DDDMM" or "+-DDMMSS+-DDDMMSS" to represent latitude and longitude according to ISO-6709 [1] standard. 1) But, the standard is used whith decimals: ±DDMM.MMM ±DDDMM.MMM (degrees and minutes) ±DDMMSS.SS ±DDDMMSS.SS (degrees, minutes and seconds) 2) Could your database to use one only way to represent the format? Or degrees and minutes; or degrees, minutes and seconds. So, the coordinates could be stored as float in the data bases, since that we know its total length. Greetings! [1] http://en.wikipedia.org/wiki/ISO_6709

2 1

"Extended" POSIX time zone string?
by Olson, Arthur David (NIH/NCI) [E] Feb. 3, 2009

Feb. 3, 2009

Future transitions in a zone such as America/Godthab can't be represented by a POSIX time zone string. Transitions could be represented by a string such as... WGT-3WGST,M3.5.0/1u,M10.5.0/1u ...where the "1u" is an indication that transitions occur at 1:00 a.m. Universal time. Is this format extension (or something better) worth suggestion to the POSIX powers? --ado

1 0

Proposed time zone package changes
by Arthur David Olson Feb. 2, 2009

Feb. 2, 2009

Below find proposed relatively minor proposed changes to the time zone package: * leapseconds: updated to reflect no mid-2009 leap second * tz-art.htm: information on two CDs added * zic.c: fix fencepost error The change to zic.c will result in changed binary outputs in a handful of cases. If no one spots problems, these changes should appear at ftp://elsie on 2009-02-08. --ado diff -c -r old/leapseconds new/leapseconds *** old/leapseconds Wed Jan 14 17:35:16 2009 --- new/leapseconds Tue Jan 27 15:46:54 2009 *************** *** 1,4 **** ! # @(#)leapseconds 8.6 # Allowance for leapseconds added to each timezone file. --- 1,4 ---- ! # @(#)leapseconds 8.7 # Allowance for leapseconds added to each timezone file. *************** *** 53,92 **** # SERVICE DE LA ROTATION TERRESTRE # OBSERVATOIRE DE PARIS # 61, Av. de l'Observatoire 75014 PARIS (France) ! # Tel. : 33 (0) 1 40 51 22 26 # FAX : 33 (0) 1 40 51 22 91 ! # e-mail : services.iers(a)obspm.fr ! # http://hpiers.obspm.fr/eop-pc # ! # Paris, 4 July 2008 # ! # Bulletin C 36 # # To authorities responsible # for the measurement and # distribution of time # ! # UTC TIME STEP ! # on the 1st of January 2009 # ! # A positive leap second will be introduced at the end of December 2008. ! # The sequence of dates of the UTC second markers will be: # ! # 2008 December 31, 23h 59m 59s ! # 2008 December 31, 23h 59m 60s ! # 2009 January 1, 0h 0m 0s # - # The difference between UTC and the International Atomic Time TAI is: - # - # from 2006 January 1, 0h UTC, to 2009 January 1 0h UTC : UTC-TAI = - 33s - # from 2009 January 1, 0h UTC, until further notice : UTC-TAI = - 34s - # # Leap seconds can be introduced in UTC at the end of the months of December ! # or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every ! # six months, either to announce a time step in UTC or to confirm that there # will be no time step at the next possible date. # # Daniel GAMBIS ! # Head ! # Earth Orientation Center of IERS # Observatoire de Paris, France --- 53,84 ---- # SERVICE DE LA ROTATION TERRESTRE # OBSERVATOIRE DE PARIS # 61, Av. de l'Observatoire 75014 PARIS (France) ! # Tel. : 33 (0) 1 40 51 22 29 # FAX : 33 (0) 1 40 51 22 91 ! # Internet : services.iers(a)obspm.fr # ! # Paris, 15 January 2009 # ! # Bulletin C 37 # # To authorities responsible # for the measurement and # distribution of time # ! # INFORMATION ON UTC - TAI # ! # NO positive leap second will be introduced at the end of June 2009. ! # The difference between Coordinated Universal Time UTC and the ! # International Atomic Time TAI is : # ! # from 2009 January 1, 0h UTC, until further notice : UTC-TAI = -34 s # # Leap seconds can be introduced in UTC at the end of the months of December ! # or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every ! # six months, either to announce a time step in UTC, or to confirm that there # will be no time step at the next possible date. # # Daniel GAMBIS ! # Head ! # Earth Orientation Center of the IERS # Observatoire de Paris, France diff -c -r old/tz-art.htm new/tz-art.htm *** old/tz-art.htm Wed Jan 14 17:35:17 2009 --- new/tz-art.htm Sat Jan 31 11:54:12 2009 *************** *** 9,15 **** <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.10 </address> <p> Please send corrections to this web page to the --- 9,15 ---- <body> <h1>Time and the Arts</h1> <address> ! @(#)tz-art.htm 8.11 </address> <p> Please send corrections to this web page to the *************** *** 202,207 **** --- 202,231 ---- Supernaw.</td></tr> <tr><td> </td></tr> + <tr><td>Artist</td><td>The Microscopic Septet</td></tr> + <tr><td>CD</td><td>Lobster Leaps In</td></tr> + <tr><td>Copyright Date</td><td>2008</td></tr> + <tr><td>Label</td><td>Cuneiform</td></tr> + <tr><td>ID</td><td>272</td></tr> + <tr><td>Total Time</td><td>73:05</td></tr> + <tr><td>Notes</td><td>Includes the song "Twilight Time Zone."</td></tr> + <tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:w9fpxzykldje">AMG Rating</a></td><td>3.5 stars</td></tr> + <tr><td>ADO Rating</td><td>2 stars</td></tr> + + <tr><td> </td></tr> + + <tr><td>Artist</td><td>Bob Dylan</td></tr> + <tr><td>CD</td><td>The Time They Are A-Changin'</td></tr> + <tr><td>Copyright Date</td><td>1964</td></tr> + <tr><td>Label</td><td>Columbia</td></tr> + <tr><td>ID</td><td>CK-8905</td></tr> + <tr><td>Total Time</td><td>45:36</td></tr> + <tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:gifqxqt5ld0e">AMG Rating</a></td><td>4.5 stars</td></tr> + <tr><td>ADO Rating</td><td>1.5 stars</td></tr> + <tr><td>Notes<td>The title song is also available on "Bob Dylan's Greatest Hits" and "The Essential Bob Dylan."</td></tr> + + <tr><td> </td></tr> + <tr><td>TV episode title</td><td>The Lost Hour</td> <tr><td>TV series</td><td><em>Eerie, Indiana</em></td> <tr><td>TV episode number</td><td>10</td> diff -c -r old/zic.c new/zic.c *** old/zic.c Wed Jan 14 17:35:17 2009 --- new/zic.c Tue Jan 27 15:46:47 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];

1 0

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 27, 2009

Jan. 27, 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. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 27, 2009 6:52 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)elsie.nci.nih.gov Subject: RE: Bug in tz code False alarm. I looked at the older "original" output file and find the same result as in my difference list. It seems that the recent "good" file I was comparing with was truncated, some 64 lines and the tail of another line were missing from the end. These should be correct, right? TZ America/Eirunepe differences 1262218281 = 2009-12-30T20:10:57 1262220045 = 2009-12-30T20:40:21 1262221808 = 2009-12-30T21:09:44 1262222979 = 2009-12-30T21:29:15 1262224660 = 2009-12-30T21:57:16 1262225572 = 2009-12-30T22:12:28 1262227105 = 2009-12-30T22:38:01 1262228620 = 2009-12-30T23:03:16 1262230128 = 2009-12-30T23:28:24 1262231594 = 2009-12-30T23:52:50 1262232623 = 2009-12-31T00:09:59 1262233650 = 2009-12-31T00:27:06 1262234850 = 2009-12-31T00:47:06 1262236023 = 2009-12-31T01:06:39 1262237760 = 2009-12-31T01:35:36 1262239235 = 2009-12-31T02:00:11 1262240486 = 2009-12-31T02:21:02 1262242141 = 2009-12-31T02:48:37 1262243457 = 2009-12-31T03:10:33 1262244365 = 2009-12-31T03:25:41 1262245773 = 2009-12-31T03:49:09 1262247497 = 2009-12-31T04:17:53 1262249157 = 2009-12-31T04:45:33 1262250719 = 2009-12-31T05:11:35 1262251681 = 2009-12-31T05:27:37 1262253078 = 2009-12-31T05:50:54 1262254783 = 2009-12-31T06:19:19 1262256067 = 2009-12-31T06:40:43 1262257033 = 2009-12-31T06:56:49 1262257997 = 2009-12-31T07:12:53 1262259265 = 2009-12-31T07:34:01 1262260638 = 2009-12-31T07:56:54 1262261801 = 2009-12-31T08:16:17 1262263054 = 2009-12-31T08:37:10 1262264121 = 2009-12-31T08:54:57 1262265127 = 2009-12-31T09:11:43 1262266871 = 2009-12-31T09:40:47 1262268291 = 2009-12-31T10:04:27 1262269552 = 2009-12-31T10:25:28 1262270480 = 2009-12-31T10:40:56 1262271439 = 2009-12-31T10:56:55 1262272963 = 2009-12-31T11:22:19 1262273928 = 2009-12-31T11:38:24 1262275183 = 2009-12-31T11:59:19 1262276647 = 2009-12-31T12:23:43 1262277614 = 2009-12-31T12:39:50 1262279410 = 2009-12-31T13:09:46 1262280916 = 2009-12-31T13:34:52 1262282596 = 2009-12-31T14:02:52 1262283975 = 2009-12-31T14:25:51 1262285281 = 2009-12-31T14:47:37 1262286458 = 2009-12-31T15:07:14 1262287985 = 2009-12-31T15:32:41 1262289282 = 2009-12-31T15:54:18 1262290422 = 2009-12-31T16:13:18 1262291367 = 2009-12-31T16:29:03 1262293039 = 2009-12-31T16:56:55 1262294198 = 2009-12-31T17:16:14 1262295285 = 2009-12-31T17:34:21 1262296885 = 2009-12-31T18:01:01 1262298068 = 2009-12-31T18:20:44 1262299259 = 2009-12-31T18:40:35 1262300783 = 2009-12-31T19:05:59 1262302548 = 2009-12-31T19:35:24 -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Tuesday, January 27, 2009 2:58 PM To: tz(a)elsie.nci.nih.gov Cc: John Dlugosz Subject: RE: Bug in tz code The pre- and post- fencepost fix Eirunepe binary outputs are the same here on the mother ship; is anyone else seeing a glitch? --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Monday, January 26, 2009 8:38 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)lecserver.nci.nih.gov Subject: RE: Bug in tz code ...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.

1 0

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 27, 2009

Jan. 27, 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. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Monday, January 26, 2009 8:38 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)lecserver.nci.nih.gov Subject: RE: Bug in tz code 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(a)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];

2 2

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 26, 2009

Jan. 26, 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. --ado From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Thursday, January 22, 2009 3:59 To: tz(a)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

2 3

zic files: where is "Indian"?
by John Dlugosz Jan. 26, 2009

Jan. 26, 2009

I have files such as "Indian/Kerguelan", but I can't find that in any of the zic input files. I can't find any mention of "Indian" at all, other than in zone.tab. What am I missing? --John

1 0

Bug in tz code
by John Dlugosz Jan. 22, 2009

Jan. 22, 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

1 0

leapseconds - Bulletin C 37
by Edwin Groothuis Jan. 22, 2009

Jan. 22, 2009

http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat Bulletin C37 says: NO positive leap second will be introduced at the end of June 2009.

1 0

zdump on 64bit architectures being worked on?
by Stuart Bishop Jan. 21, 2009

Jan. 21, 2009

Hi. Is anyone looking at getting zdump(1) working on 64bit systems? http://thread.gmane.org/gmane.comp.time.tz/2155/focus=2156 https://bugs.launchpad.net/pytz/+bug/213816 I'm currently parsing its output to generate some test suites and I'm one 4 year old laptop away from having no 32bit systems to work on... -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/

7 11

tzcode2009a.tar.gz and tzdata2009a.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Jan. 21, 2009

Jan. 21, 2009

The files... ftp://elsie.nci.nih.gov/pub/tzcode2009a.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2009a.tar.gz ...are now available; these reflect the changes circulated last week on the time zone mailing list (minus the addition of a Geneva zone). --ado

1 0

proposed time zone package changes
by Arthur David Olson Jan. 18, 2009

Jan. 18, 2009

Here are proposed time zone package changes, preceded by a list of files to be changed and reasons for the changes. If these pass muster, tzcode2009a.tar.gz and tzdata2009a.tar.tz will appear a week from today (on an unusual Wednesday since both Monday and Tuesday are leave days for U. S. federal employees in the Washington, D. C. area). --ado * asia change Katmandu to Kathmandu * backward provide Katmandu link * europe correct Swiss rules; add Europe/Geneva * northamerica clearer definition of Cuban transitions (no binary change) Resolute changes abbreviation (but not time) twice a year * strftime.c c format warning fix * tzselect.ksh --help and --version handling * zdump.c --help and --version handling * zic.c --help and --version handling fix infinite loop caused by overflow/optimization interaction * zone.tab Change Katmandu to Kathmandu Change Resolute from Eastern Time to Eastern Standard Time Add Europe/Geneva diff -r -c old/asia new/asia *** old/asia Wed Oct 8 08:35:57 2008 --- new/asia Wed Jan 14 11:15:49 2009 *************** *** 1,4 **** ! # @(#)asia 8.24 # <pre> # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)asia 8.25 # <pre> # This data is by no means authoritative; if you think you know better, *************** *** 1474,1480 **** # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Katmandu 5:41:16 - LMT 1920 5:30 - IST 1986 5:45 - NPT # Nepal Time --- 1474,1480 ---- # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:30 - IST 1986 5:45 - NPT # Nepal Time diff -r -c old/backward new/backward *** old/backward Tue Sep 9 22:33:26 2008 --- new/backward Wed Jan 14 11:15:49 2009 *************** *** 1,4 **** ! # @(#)backward 8.6 # This file provides links between current names for time zones # and their old names. Many names changed in late 1993. --- 1,4 ---- ! # @(#)backward 8.7 # This file provides links between current names for time zones # and their old names. Many names changed in late 1993. *************** *** 24,29 **** --- 24,30 ---- Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Chongqing Asia/Chungking Link Asia/Dhaka Asia/Dacca + Link Asia/Kathmandu Asia/Katmandu Link Asia/Kolkata Asia/Calcutta Link Asia/Macau Asia/Macao Link Asia/Jerusalem Asia/Tel_Aviv diff -r -c old/europe new/europe *** old/europe Tue Sep 9 22:33:25 2008 --- new/europe Wed Jan 14 13:37:27 2009 *************** *** 1,4 **** ! # @(#)europe 8.18 # <pre> # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)europe 8.19 # <pre> # This data is by no means authoritative; if you think you know better, *************** *** 2313,2328 **** # mean time in preference to apparent time -- Geneva from 1780 .... # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # From Whitman (who writes ``Midnight?''): ! Rule Swiss 1940 only - Nov 2 0:00 1:00 S ! Rule Swiss 1940 only - Dec 31 0:00 0 - # From Shanks & Pottenger: ! Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S ! Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT # Turkey --- 2313,2384 ---- # mean time in preference to apparent time -- Geneva from 1780 .... # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # From Whitman (who writes ``Midnight?''): ! # Rule Swiss 1940 only - Nov 2 0:00 1:00 S ! # Rule Swiss 1940 only - Dec 31 0:00 0 - # From Shanks & Pottenger: ! # Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S ! # Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 - ! ! # From Alois Treindl (2008-12-17): ! # I have researched the DST usage in Switzerland during the 1940ies. ! # ! # As I wrote in an earlier message, I suspected the current tzdata values ! # to be wrong. This is now verified. ! # ! # I have found copies of the original ruling by the Swiss Federal ! # government, in 'Eidgen[o]ssische Gesetzessammlung 1941 and 1942' (Swiss ! # federal law collection)... ! # ! # DST began on Monday 5 May 1941, 1:00 am by shifting the clocks to 2:00 am ! # DST ended on Monday 6 Oct 1941, 2:00 am by shifting the clocks to 1:00 am. ! # ! # DST began on Monday, 4 May 1942 at 01:00 am ! # DST ended on Monday, 5 Oct 1942 at 02:00 am ! # ! # There was no DST in 1940, I have checked the law collection carefully. ! # It is also indicated by the fact that the 1942 entry in the law ! # collection points back to 1941 as a reference, but no reference to any ! # other years are made. ! # ! # Newspaper articles I have read in the archives on 6 May 1941 reported ! # about the introduction of DST (Sommerzeit in German) during the previous ! # night as an absolute novelty, because this was the first time that such ! # a thing had happened in Switzerland. ! # ! # I have also checked 1916, because one book source (Gabriel, Traite de ! # l'heure dans le monde) claims that Switzerland had DST in 1916. This is ! # false, no official document could be found. Probably Gabriel got misled ! # by references to Germany, which introduced DST in 1916 for the first time. ! # ! # The tzdata rules for Switzerland must be changed to: ! # Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S ! # Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - ! # ! # The 1940 rules must be deleted. ! # ! # One further detail for Switzerland, which is probably out of scope for ! # most users of tzdata: ! # The zone file ! # Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 ! # 0:29:44 - BMT 1894 Jun #Bern Mean Time ! # 1:00 Swiss CE%sT 1981 ! # 1:00 EU CE%sT ! # describes all of Switzerland correctly, with the exception of ! # the Cantone Geneve (Geneva, Genf). Between 1848 and 1894 Geneve did not ! # follow Bern Mean Time but kept its own local mean time. ! # To represent this, an extra zone would be needed. ! ! # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S ! Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT + Zone Europe/Geneva 0:24:56 - LMT 1894 Jun # avoid GMT + 1:00 Swiss CE%sT 1981 + 1:00 EU CE%sT # Turkey diff -r -c old/northamerica new/northamerica *** old/northamerica Tue Sep 9 16:05:43 2008 --- new/northamerica Wed Jan 14 12:32:15 2009 *************** *** 1,4 **** ! # @(#)northamerica 8.24 # <pre> # also includes Central America and the Caribbean --- 1,4 ---- ! # @(#)northamerica 8.26 # <pre> # also includes Central America and the Caribbean *************** *** 1742,1751 **** # The individual that answered the phone confirmed that the clocks did not # move at the end of daylight saving on October 29/2006. He also told me that # the clocks did not move this past weekend (March 11/2007).... - # - # America/Resolute should use the "Canada" Rule up to October 29/2006. - # After that it should be fixed on Eastern Standard Time until further notice. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NT_YK 1918 only - Apr 14 2:00 1:00 D Rule NT_YK 1918 only - Oct 27 2:00 0 S --- 1742,1755 ---- # The individual that answered the phone confirmed that the clocks did not # move at the end of daylight saving on October 29/2006. He also told me that # the clocks did not move this past weekend (March 11/2007).... + # From Chris Walton (2008-11-13): + # ...the residents of Resolute believe that they are changing "time zones" + # twice a year. In winter months, local time is qualified with "Eastern + # Time" which is really "Eastern Standard Time (UTC-5)". In summer + # months, local time is qualified with "Central Time" which is really + # "Central Daylight Time (UTC-5)"... + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NT_YK 1918 only - Apr 14 2:00 1:00 D Rule NT_YK 1918 only - Oct 27 2:00 0 S *************** *** 1772,1782 **** -6:00 Canada C%sT 2000 Oct 29 2:00 -5:00 Canada E%sT # aka Qausuittuq Zone America/Resolute 0 - zzz 1947 Aug 31 # Resolute founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 -5:00 - EST 2001 Apr 1 3:00 -6:00 Canada C%sT 2006 Oct 29 2:00 ! -5:00 - EST # aka Kangiqiniq Zone America/Rankin_Inlet 0 - zzz 1957 # Rankin Inlet founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 --- 1776,1789 ---- -6:00 Canada C%sT 2000 Oct 29 2:00 -5:00 Canada E%sT # aka Qausuittuq + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S + Rule Resolute 2006 max - Nov Sun>=1 2:00 0 ES + Rule Resolute 2007 max - Mar Sun>=8 2:00 0 CD Zone America/Resolute 0 - zzz 1947 Aug 31 # Resolute founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 -5:00 - EST 2001 Apr 1 3:00 -6:00 Canada C%sT 2006 Oct 29 2:00 ! -5:00 Resolute %sT # aka Kangiqiniq Zone America/Rankin_Inlet 0 - zzz 1957 # Rankin Inlet founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 *************** *** 2280,2286 **** Rule Cuba 1997 only - Oct 12 0:00s 0 S Rule Cuba 1998 1999 - Mar lastSun 0:00s 1:00 D Rule Cuba 1998 2003 - Oct lastSun 0:00s 0 S ! Rule Cuba 2000 2006 - Apr Sun>=1 0:00s 1:00 D Rule Cuba 2006 max - Oct lastSun 0:00s 0 S Rule Cuba 2007 only - Mar Sun>=8 0:00s 1:00 D Rule Cuba 2008 max - Mar Sun>=15 0:00s 1:00 D --- 2287,2293 ---- Rule Cuba 1997 only - Oct 12 0:00s 0 S Rule Cuba 1998 1999 - Mar lastSun 0:00s 1:00 D Rule Cuba 1998 2003 - Oct lastSun 0:00s 0 S ! Rule Cuba 2000 2004 - Apr Sun>=1 0:00s 1:00 D Rule Cuba 2006 max - Oct lastSun 0:00s 0 S Rule Cuba 2007 only - Mar Sun>=8 0:00s 1:00 D Rule Cuba 2008 max - Mar Sun>=15 0:00s 1:00 D diff -r -c old/strftime.c new/strftime.c *** old/strftime.c Mon Sep 15 09:24:42 2008 --- new/strftime.c Wed Jan 14 12:33:56 2009 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 8.2"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 8.3"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 216,222 **** { int warn2 = IN_SOME; ! pt = _fmt(Locale->c_fmt, t, pt, ptlim, warnp); if (warn2 == IN_ALL) warn2 = IN_THIS; if (warn2 > *warnp) --- 216,222 ---- { int warn2 = IN_SOME; ! pt = _fmt(Locale->c_fmt, t, pt, ptlim, &warn2); if (warn2 == IN_ALL) warn2 = IN_THIS; if (warn2 > *warnp) diff -r -c old/tzselect.ksh new/tzselect.ksh *** old/tzselect.ksh Tue Sep 9 22:33:17 2008 --- new/tzselect.ksh Wed Jan 14 10:56:24 2009 *************** *** 1,6 **** #! /bin/ksh ! # '@(#)tzselect.ksh 8.1' # Ask the user about the time zone, and output the resulting TZ value to stdout. # Interact with the user via stderr and stdin. --- 1,6 ---- #! /bin/ksh ! VERSION='@(#)tzselect.ksh 8.2' # Ask the user about the time zone, and output the resulting TZ value to stdout. # Interact with the user via stderr and stdin. *************** *** 45,50 **** --- 45,65 ---- exit 1 } + if [ "$1" = "--help" ]; then + cat <<EOF + Usage: tzselect + Select a time zone interactively. + + Report bugs to tz(a)elsie.nci.nih.gov. + EOF + exit 0 + elif [ "$1" = "--version" ]; then + cat <<EOF + tzselect $VERSION + EOF + exit 0 + fi + # Make sure the tables are readable. TZ_COUNTRY_TABLE=$TZDIR/iso3166.tab TZ_ZONE_TABLE=$TZDIR/zone.tab diff -r -c old/zdump.c new/zdump.c *** old/zdump.c Tue Sep 9 22:33:24 2008 --- new/zdump.c Wed Jan 14 11:01:56 2009 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 8.6"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 8.8"; /* ** This code has been made independent of the rest of the time *************** *** 230,235 **** --- 230,246 ---- warned = TRUE; } + static void + usage(const char *progname, FILE *stream, int status) + { + (void) fprintf(stream, + _("%s: usage is %s [ --version ] [ --help ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n\ + \n\ + Report bugs to tz(a)elsie.nci.nih.gov.\n"), + progname, progname); + exit(status); + } + int main(argc, argv) int argc; *************** *** 266,271 **** --- 277,284 ---- if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(progname, stdout, EXIT_SUCCESS); } vflag = 0; cutarg = NULL; *************** *** 275,284 **** else cutarg = optarg; if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { ! (void) fprintf(stderr, ! _("%s: usage is %s [ --version ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n"), ! progname, progname); ! exit(EXIT_FAILURE); } if (vflag) { if (cutarg != NULL) { --- 288,294 ---- else cutarg = optarg; if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { ! usage(progname, stderr, EXIT_FAILURE); } if (vflag) { if (cutarg != NULL) { *************** *** 349,361 **** (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); } for ( ; ; ) { ! if (t >= cuthitime) break; newt = t + SECSPERHOUR * 12; - if (newt >= cuthitime) - break; - if (newt <= t) - break; newtmp = localtime(&newt); if (newtmp != NULL) newtm = *newtmp; --- 359,367 ---- (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); } for ( ; ; ) { ! if (t >= cuthitime || t >= cuthitime - SECSPERHOUR * 12) break; newt = t + SECSPERHOUR * 12; newtmp = localtime(&newt); if (newtmp != NULL) newtm = *newtmp; diff -r -c old/zic.c new/zic.c *** old/zic.c Tue Sep 9 22:33:18 2008 --- new/zic.c Wed Jan 14 10:59:48 2009 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.17"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.18"; #include "private.h" #include "locale.h" *************** *** 156,162 **** const struct zone * zp, int ntzones); static void setboundaries(void); static zic_t tadd(zic_t t1, long t2); ! static void usage(void); static void writezone(const char * name, const char * string); static int yearistype(int year, const char * type); --- 156,162 ---- const struct zone * zp, int ntzones); static void setboundaries(void); static zic_t tadd(zic_t t1, long t2); ! static void usage(FILE *stream, int status); static void writezone(const char * name, const char * string); static int yearistype(int year, const char * type); *************** *** 454,466 **** } static void ! usage(void) { ! (void) fprintf(stderr, _("%s: usage is %s \ ! [ --version ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ ! \t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), ! progname, progname); ! exit(EXIT_FAILURE); } static const char * psxrules; --- 454,468 ---- } static void ! usage(FILE *stream, int status) { ! (void) fprintf(stream, _("%s: usage is %s \ ! [ --version ] [ --help ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ ! \t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n\ ! \n\ ! Report bugs to tz(a)elsie.nci.nih.gov.\n"), ! progname, progname); ! exit(status); } static const char * psxrules; *************** *** 498,508 **** if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); } while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF && c != -1) switch (c) { default: ! usage(); case 'd': if (directory == NULL) directory = optarg; --- 500,512 ---- if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(stdout, EXIT_SUCCESS); } while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF && c != -1) switch (c) { default: ! usage(stderr, EXIT_FAILURE); case 'd': if (directory == NULL) directory = optarg; *************** *** 561,567 **** break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) ! usage(); /* usage message by request */ if (directory == NULL) directory = TZDIR; if (yitcommand == NULL) --- 565,571 ---- break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) ! usage(stderr, EXIT_FAILURE); /* usage message by request */ if (directory == NULL) directory = TZDIR; if (yitcommand == NULL) diff -r -c old/zone.tab new/zone.tab *** old/zone.tab Tue Oct 21 12:10:25 2008 --- new/zone.tab Wed Jan 14 13:40:29 2009 *************** *** 1,4 **** ! # @(#)zone.tab 8.21 # # TZ zone descriptions # --- 1,4 ---- ! # @(#)zone.tab 8.25 # # TZ zone descriptions # *************** *** 116,122 **** CA +4823-08915 America/Thunder_Bay Eastern Time - Thunder Bay, Ontario CA +6344-06828 America/Iqaluit Eastern Time - east Nunavut - most locations CA +6608-06544 America/Pangnirtung Eastern Time - Pangnirtung, Nunavut ! CA +744144-0944945 America/Resolute Eastern Time - Resolute, Nunavut CA +484531-0913718 America/Atikokan Eastern Standard Time - Atikokan, Ontario and Southampton I, Nunavut CA +624900-0920459 America/Rankin_Inlet Central Time - central Nunavut CA +4953-09709 America/Winnipeg Central Time - Manitoba & west Ontario --- 116,122 ---- CA +4823-08915 America/Thunder_Bay Eastern Time - Thunder Bay, Ontario CA +6344-06828 America/Iqaluit Eastern Time - east Nunavut - most locations CA +6608-06544 America/Pangnirtung Eastern Time - Pangnirtung, Nunavut ! CA +744144-0944945 America/Resolute Eastern Standard Time - Resolute, Nunavut CA +484531-0913718 America/Atikokan Eastern Standard Time - Atikokan, Ontario and Southampton I, Nunavut CA +624900-0920459 America/Rankin_Inlet Central Time - central Nunavut CA +4953-09709 America/Winnipeg Central Time - Manitoba & west Ontario *************** *** 136,142 **** CD -1140+02728 Africa/Lubumbashi east Dem. Rep. of Congo CF +0422+01835 Africa/Bangui CG -0416+01517 Africa/Brazzaville ! CH +4723+00832 Europe/Zurich CI +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago most locations --- 136,143 ---- CD -1140+02728 Africa/Lubumbashi east Dem. Rep. of Congo CF +0422+01835 Africa/Bangui CG -0416+01517 Africa/Brazzaville ! CH +4723+00832 Europe/Zurich most locations ! CH +4614+00604 Europe/Geneva Geneva only CI +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago most locations *************** *** 292,298 **** NI +1209-08617 America/Managua NL +5222+00454 Europe/Amsterdam NO +5955+01045 Europe/Oslo ! NP +2743+08519 Asia/Katmandu NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ -3652+17446 Pacific/Auckland most locations --- 293,299 ---- NI +1209-08617 America/Managua NL +5222+00454 Europe/Amsterdam NO +5955+01045 Europe/Oslo ! NP +2743+08519 Asia/Kathmandu NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ -3652+17446 Pacific/Auckland most locations

4 3

(resend) What are tt_ttisstd and tt_ttisgmt for?
by John Dlugosz Jan. 16, 2009

Jan. 16, 2009

I thought I understood the comment in the file structure, ** one (char [4]) total correction after above ** tzh_ttisstdcnt (char)s indexed by type; if TRUE, transition ** time is standard time, if FALSE, ** transition time is wall clock time ** if absent, transition times are ** assumed to be wall clock time ** tzh_ttisgmtcnt (char)s indexed by type; if TRUE, transition ** time is UTC, if FALSE, ** transition time is local time ** if absent, transition times are ** assumed to be local time but, I don't see them being used the logic to search ats, or to adjust the ats values after loading. So if present in the data file they do nothing. In fact, I got rid of the TRUE's in one of the data files, and it did not make the program produce any different results. What am I missing? Thanks, --John

1 0

FW: Australian DST abbreviations causing business problems - still
by Olson, Arthur David (NIH/NCI) [E] Jan. 15, 2009

Jan. 15, 2009

I'm forwarding this message from Mick Johnston, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Mick Johnston [mailto:Mick.Johnston@coles.com.au] Sent: Tuesday, August 26, 2008 1:42 To: 'tz(a)elsie.nci.nih.gov' Subject: Australian DST abbreviations causing business problems - still It's well past time the Australian 'Daylight Saving Time' abbreviations were updated to reflect the current terms and usage. Comments posted previously in the 'australasia' file are outdated and wrong and have been causing lots of problems for years. You don't have to take my word for this. Although most of the URLs identified in the file are not official sites and Daylight Saving Time is legislated by state governments, the exemplary abbreviations are displayed at the Australian federal government website at <http://www.australia.gov.au/Time#daylightsaving> as at 26/8/08. Here is the important bit: Quote: Where daylight saving is being observed: * AEST becomes Australian Eastern Daylight Time (AEDT), and clocks are advanced to UTC +11. * ACST becomes Australian Central Daylight Time (ACDT), and clocks are advanced to UTC +10 ½. * AWST becomes Australian Western Daylight Time (AWDT), and clocks are advanced to UTC +9. " Unquote: The abbreviations AEDT, ACDT and AWDT are commonly shortened to EDT, CDT and WDT. Is there really a problem? Yes. I work for a national retail company that makes deliveries across the country. Here is just one example of the sorts of problems we face. Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused. If the problem impacts businesses, then why don't they use their own time zone tables? It's not that simple. It's quite common today to find systems (like ours) that are purchased on an enterprise licence basis from a large international company. It could be difficult to get the company to change the base software product. Also, it's common for software products to run on standard operating systems such as the AIX flavour of Unix, and for the software products to use whatever time zone information is applied by the operating system. Try getting the operating system vendor to change their software and they'll simply tell you it's based on the Olsen updates. Then why hasn't the table been changed already? To answer this question, I need to address some of the comments previously made in the 'australasia' file. The first comment on this subject in the file was made by John Mackin back in 1991: JM:" We in Australia have _never_ referred to DST as `daylight' time. It is called `summer' time." MJ: This comment is more than 17 years old and horribly outdated. I have lived in Australia all my life and have been supporting systems here since well before 1991. Most Australians simply use the term 'Daylight Saving Time'. It's uncommon outside the business environment to use any other term. In business and government, Australians recognized the problems associated with ambiguous abbreviations a long time ago and have generally adopted the 'EDT' form. Various federal government websites (although not official), in an attempt to encourage uniformity, have been displaying the newer abbreviations for some time. See <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> <http://www.australia.gov.au/Time#daylightsaving> Paul Eggert wrote an interesting post in 2001 that needs to be addressed. PE: "My own impression is that both "Daylight Time" and "Summer Time" are common and are widely understood, but that "Summer Time" is more popular;" MJ: Based on my day-to-day observations and discussions with people across states, most Australians now don't use the term 'Eastern Summer Time'. PE: "I just used AltaVista advanced search and got the following count of page hits: 1,103 "Eastern Summer Time" AND domain:au 971 "Australian Eastern Summer Time" AND domain:au 613 "Eastern Daylight Time" AND domain:au 127 "Australian Eastern Daylight Time" AND domain:au" MJ: I just googled (26/8/08) similar searches based on an "Australia only" search and my results were: 30,500 - "eastern daylight time" 5,640 - "eastern summer time" PE: "For abbreviations, tools like AltaVista are less useful because of ambiguity. Many hits are not really time zones, unfortunately, and many hits denote US time zones and not Australian ones. But here are the hit counts anyway: 161,304 "EST" and domain:au 25,156 "EDT" and domain:au" MJ: I agree with your comments, which means the figures are totally inaccurate. File Changes: Due to the fact that the file forms part of the JTZU (Java Time Zone Updates) provided by the operating system vendor, I am unable to create and test proposed changes. Also, there are quite a few changes required and I don't want to spend hours making these changes if they're not going to be applied. I ask for your advice on how to proceed with this. I am happy to work with you to produce a complete set of revised rules if you decide to go ahead with this proposal. We will need to change Aus, AW, AS, AT, AV and AN rules and their corresponding zone formats to use the 'E%sT' format. Thanks for your time and assistance Mick Johnston Dept: CGL - IT ES Supply Chain * L4 Bourke St. Melbourne (ILS Support) * (03) 9635 4457 This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material.

9 14

FW: Notes on 'timesub"
by Olson, Arthur David (NIH/NCI) [E] Jan. 15, 2009

Jan. 15, 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. --ado From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Thursday, January 15, 2009 12:40 To: tz(a)lecserver.nci.nih.gov Subject: Notes on 'timesub" The implementation of 'timesub' uses quite a bit of complex logic, approximations, and looping to do what can be done with a single expression. The part of the function that digests the number of days into y/m/d fields has been known since before computers as "Julian Day Number" and that can be harnessed directly simply by subtracting a constant for the Epoch base. Here is my version, which is not so digested into my own library that you can't follow the logic: void timezone_t::state::timesub ( const __time64_t t, // input time number const long offset, // added to time, but figures date from original (e.g. like a denormal value) ymd_hms& tmp // output ) const { // more complex than it needs to be! static const int JDayEpoch= Julian_day_number (ymd(EPOCH_YEAR, 1, 1)); int days_in_epoch = t / SECSPERDAY; int rem = t - days_in_epoch * SECSPERDAY; int corr= count_leap_seconds (JDayEpoch, JDayEpoch+days_in_epoch); tmp= Julian_day_number (JDayEpoch+days_in_epoch); tmp.set_normalized (hms(0,0,rem+offset - corr)); } In your code, the part I'm referring to is the middle. First it finds 'corr' for leap seconds, and afterwards it adds the seconds into the h/m/s possibly overflowing into the d/m/y. I have those in callable functions, but the approach is the same. It's just that the middle part, converting a number of seconds into y/m/d, is not as hard as you make it out to be. This is a direct implementation of the published formula, which involves no looping or successive approximations or peeling off each month individually: ymd Julian_day_number (int J) { const int j= J+32044; const int g= j / 146097; const int dg= j % 146097; const int c= (dg / 36524 + 1) * 3 / 4; const int dc= dg - c * 36524; const int b= dc / 1461; const int db= dc % 1461; const int a= (db/365+1) * 3 / 4; const int da= db - a * 365; const int y= g*400 + c*100 + b*4 + a; const int m= (da*5+308) / 153 - 2; const int d= da - (m+4) *153 / 5 + 122; return ymd (y-4800+(m+2)/12, (m+2)%12+1, d+1); } (The comment that it is (still) more complex than it needs to be is because the normalization code in my library can handle that directly, so I can just call existing code.) --John

1 0

Notes on 'timesub"
by John Dlugosz Jan. 15, 2009

Jan. 15, 2009

The implementation of 'timesub' uses quite a bit of complex logic, approximations, and looping to do what can be done with a single expression. The part of the function that digests the number of days into y/m/d fields has been known since before computers as "Julian Day Number" and that can be harnessed directly simply by subtracting a constant for the Epoch base. Here is my version, which is not so digested into my own library that you can't follow the logic: void timezone_t::state::timesub ( const __time64_t t, // input time number const long offset, // added to time, but figures date from original (e.g. like a denormal value) ymd_hms& tmp // output ) const { // more complex than it needs to be! static const int JDayEpoch= Julian_day_number (ymd(EPOCH_YEAR, 1, 1)); int days_in_epoch = t / SECSPERDAY; int rem = t - days_in_epoch * SECSPERDAY; int corr= count_leap_seconds (JDayEpoch, JDayEpoch+days_in_epoch); tmp= Julian_day_number (JDayEpoch+days_in_epoch); tmp.set_normalized (hms(0,0,rem+offset - corr)); } In your code, the part I'm referring to is the middle. First it finds 'corr' for leap seconds, and afterwards it adds the seconds into the h/m/s possibly overflowing into the d/m/y. I have those in callable functions, but the approach is the same. It's just that the middle part, converting a number of seconds into y/m/d, is not as hard as you make it out to be. This is a direct implementation of the published formula, which involves no looping or successive approximations or peeling off each month individually: ymd Julian_day_number (int J) { const int j= J+32044; const int g= j / 146097; const int dg= j % 146097; const int c= (dg / 36524 + 1) * 3 / 4; const int dc= dg - c * 36524; const int b= dc / 1461; const int db= dc % 1461; const int a= (db/365+1) * 3 / 4; const int da= db - a * 365; const int y= g*400 + c*100 + b*4 + a; const int m= (da*5+308) / 153 - 2; const int d= da - (m+4) *153 / 5 + 122; return ymd (y-4800+(m+2)/12, (m+2)%12+1, d+1); } (The comment that it is (still) more complex than it needs to be is because the normalization code in my library can handle that directly, so I can just call existing code.) --John

1 0

FW: timezone code - re-entrancy issue
by Olson, Arthur David (NIH/NCI) [E] Jan. 14, 2009

Jan. 14, 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. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 06, 2009 7:36 To: tz(a)lecserver.nci.nih.gov Subject: timezone code - re-entrancy issue At the bottom of localsub, tzname[tmp->tm_isdst] = &sp->chars[ttisp->tt_abbrind]; I think this is to update the tzname string to the last time zone abbr. actually used in to produce the tm values. It is not re-entrant. This is called even by localtime_r, which may be changing the values even as another thread (who called plain localtime) is reading it. It also changes all the time as the "binary search" is being done by mktime. That violates the "behaves as if never called" rule, and putting it in a subroutine doesn't help there. Am I missing something? --John

4 11

What are tt_ttisstd and tt_ttisgmt for?
by John Dlugosz Jan. 14, 2009

Jan. 14, 2009

I thought I understood the comment in the file structure, ** one (char [4]) total correction after above ** tzh_ttisstdcnt (char)s indexed by type; if TRUE, transition ** time is standard time, if FALSE, ** transition time is wall clock time ** if absent, transition times are ** assumed to be wall clock time ** tzh_ttisgmtcnt (char)s indexed by type; if TRUE, transition ** time is UTC, if FALSE, ** transition time is local time ** if absent, transition times are ** assumed to be local time but, I don't see them being used the logic to search ats, or to adjust the ats values after loading. So if present in the data file they do nothing. In fact, I got rid of the TRUE's in one of the data files, and it did not make the program produce any different results. What am I missing?

1 0