- tz - lists.iana.org

"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. 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 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