- tz - lists.iana.org

FW: Wrong Argentinian DST introduced in version 2008f
by Olson, Arthur David (NIH/NCI) [E] Dec. 11, 2008

Dec. 11, 2008

I'm forwarding this message from Aurelien Jarno, who is not on the time zone mailing list. Those of you who are on the time zone mailing list, please direct replies appropriately. --ado -----Original Message----- From: Aurelien Jarno [mailto:aurelien@aurel32.net] Sent: Monday, October 06, 2008 9:29 To: tz(a)lecserver.nci.nih.gov Subject: Wrong Argentinian DST introduced in version 2008f Hi, tzdata version 2008f introduced a rule for Argentinian DST based on http://www.worldtimezone.com/dst_news/dst_news_argentina03.html and http://www.impulsobaires.com.ar/nota.php?id=57832 Unfortunately those links only speak about rumors of a DST change, there is nothing fixed officially, and according to some Argentinian people DST may even not happen this year. Until an official decision is taken it is probably a lot better to remove any DST rule for year 2008. Please find attached a patch to do that. Regards, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32(a)debian.org | aurelien(a)aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net

4 3

Fwd: zdump loop problem
by Jonathan Leffler Dec. 11, 2008

Dec. 11, 2008

Originally sent to the wrong email address - sorry. ---------- Forwarded message ---------- From: Jonathan Leffler <jonathan.leffler(a)gmail.com> Date: Mon, Dec 8, 2008 at 12:14 PM Subject: Re: zdump loop problem To: Robbin Kawabata <Robbin.Kawabata(a)sun.com> Cc: tz(a)lecserver.nci.nih.gov, a.radke(a)arcor.de On Mon, Dec 8, 2008 at 11:50 AM, Robbin Kawabata <Robbin.Kawabata(a)sun.com>wrote: > I ran ado's fix against all the timezones, and got good results. > > This is the diff: > > *** zdump_loop.c Tue Dec 2 11:17:01 2008 > --- zdump_fix_ado.c Tue Dec 2 12:49:05 2008 > *************** > *** 312,322 **** > (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); > --- 312,320 ---- > (void) strncpy(buf, abbr(&tm), sizeof (buf) - 1); > } > for (;;) { > ! if (t >= cuthitime || t >= cuthitime - SECSPERHOUR > * 12) > break; > Isn't that code equivalent to just: if (t >= cuthitime - SECSPERHOUR * 12) I've not followed all the details of the thread, but AFAIUI, this code is protecting against overflow on positive quantities (rather than underflow on negative ones), and the double test is redundant unless cuthitime is within 12 * SECPERHOUR of the smallest (most negative) integer. > newt = t + SECSPERHOUR * 12; > if (newt <= t) > break; > newtmp = localtime(&newt); > > > However, isn't the check for "if (newt <= t) break" no longer needed? > Probably... > ----- Begin Forwarded Message ----- > > Date: Mon, 01 Dec 2008 16:21:00 -0500 > From: "Olson, Arthur David (NIH/NCI) [E]" <olsona(a)dc37a.nci.nih.gov> > Subject: Re: zdump loop problem > To: tz(a)lecserver.nci.nih.gov > Cc: Andreas Radke <a.radke(a)arcor.de> > > So...in the real world, does changing the zic.c lines reading... > if (t >= cuthitime) > break; > newt = t + SECSPERHOUR * 12; > if (newt >= cuthitime) > break; > ...to read... > if (t >= cuthitime || t >= cuthitime - > SECSPERHOUR * 12) > break; > newt = t + SECSPERHOUR * 12; > ...result in working code? I'd particularly appreciate feedback from > Andreas Radke or other ArchLinux users. > > ----- End Forwarded Message ----- > -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

FW: Cuba 2004-2006
by Olson, Arthur David (NIH/NCI) [E] Dec. 10, 2008

Dec. 10, 2008

I'm forwarding this message from hsv(a)tbbs.net, who is not on the time zone mailing list (at least not at that address). Those of you who are on the list, please direct replies appropriately. Hsv is correct that there's no real shift in April 2005 or April 2006. While the current rules do the right thing, I plan to include a change from... Rule Cuba 2000 2006 - Apr Sun>=1 0:00s 1:00 D ...to... Rule Cuba 2000 2004 - Apr Sun>=1 0:00s 1:00 D ...in the next bundle of changes for clarity. --ado -----Original Message----- From: hsv(a)tbbs.net [mailto:hsv@tbbs.net] Sent: Sunday, December 07, 2008 12:19 To: tz(a)lecserver.nci.nih.gov Subject: Cuba 2004-2006 This looks queer: 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 I take the foregoing for something like this: ... 2003 Apr Sun>=1 0:00s 1:00 D 2003 Oct lastSun 0:00s 0 S 2004 Apr Sun>=1 0:00s 1:00 D 2005 Apr Sun>=1 0:00s 1:00 D 2006 Apr Sun>=1 0:00s 1:00 D 2006 Oct lastSun 0:00s 0 S ... but at those Aprils in 2005 and 2006 there is no real shift. Is this right?

1 0

Brazil rule issue
by Alain Petit Dec. 10, 2008

Dec. 10, 2008

Hi I am looking in the Brazil rules and I was wondering if this was expected: <snapshot> Rule Brazil 2007 only - Oct Sun>=8 0:00 1:00 S # From Frederico A. C. Neves (2008-09-10): # Acording to this decree # <a href="http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm"> # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm # </a> # [t]he DST period in Brazil now on will be from the 3rd Oct Sunday to the # 3rd Feb Sunday. There is an exception on the return date when this is # the Carnival Sunday then the return date will be the next Sunday... Rule Brazil 2008 max - Oct Sun>=15 0:00 1:00 S Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - Rule Brazil 2016 2022 - Feb Sun>=15 0:00 0 - Rule Brazil 2023 only - Feb Sun>=22 0:00 0 - Rule Brazil 2024 2025 - Feb Sun>=15 0:00 0 - Rule Brazil 2026 only - Feb Sun>=22 0:00 0 - Rule Brazil 2027 2033 - Feb Sun>=15 0:00 0 - Rule Brazil 2034 only - Feb Sun>=22 0:00 0 - Rule Brazil 2035 2036 - Feb Sun>=15 0:00 0 - Rule Brazil 2037 only - Feb Sun>=22 0:00 0 - # From Arthur David Olson (2008-09-29): # The next is wrong in some years but is better than nothing. Rule Brazil 2038 max - Feb Sun>=15 0:00 0 - </snapshot> There is 2 'max' entry for Brazil, one for 2008, and one for 2038. Rule Brazil 2008 max - Oct Sun>=15 0:00 1:00 S Rule Brazil 2038 max - Feb Sun>=15 0:00 0 - Reading the entries for 2012+ I feel that the one for 2008 should be a 'only' rather than 'max'. Is that correct? Thanks Alain Petit

8 12

Re: Timezones and Holidays
by Sue Williams Dec. 9, 2008

Dec. 9, 2008

> > Hello All, > > Anyone have information on a location that would describe local/official > holidays in some sort of global format like the timezones? > > Bill Raymond > braymond <at> arinc.com Q++ Studio is another website offering comprehensive worldwide public holiday information. http://www.qppstudio.net/publicholidays.htm Here's another organization that focusses on Bank holidays: http://www.bank-holidays.com/ With a little searching, there may be more. I'm not aware of any open community effort to maintain such information. Perhaps someone else knows of something. Good luck. Susan J Williams

2 1

FW: Nepal timezone spelling
by Olson, Arthur David (NIH/NCI) [E] Dec. 9, 2008

Dec. 9, 2008

I'm forwarding this message from Phil Vandry; PV is now on the time zone mailing list. --ado -----Original Message----- From: Phil Vandry [mailto:vandry@TZoNE.ORG] Sent: Thursday, December 04, 2008 4:10 To: tz(a)lecserver.nci.nih.gov Subject: Nepal timezone spelling Hello, I propose that the name of the Asia/Katmandu zone be changed to Asia/Kathmandu. Although Katmandu is an acceptable alternate spelling, I can attest, having recently returned from a holiday in Nepal, that it is hardly ever used. In fact, I saw no occurence at all of the spelling 'Katmandu' while inside the country. This patch keeps the Katmandu spelling for backward compatibility. After trying Asia/Kathmandu and then grepping the whole database for Kathmandu, I nearly concluded that this timezone definition was missing from the database before finally finding it under the alternate spelling! -Phil --- asia.orig 2008-10-08 08:35:57.000000000 -0400 +++ asia 2008-12-04 16:05:36.000000000 -0500 @@ -1474,7 +1474,7 @@ # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Katmandu 5:41:16 - LMT 1920 +Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:30 - IST 1986 5:45 - NPT # Nepal Time --- backward.orig 2008-09-09 22:33:26.000000000 -0400 +++ backward 2008-12-04 16:05:28.000000000 -0500 @@ -24,6 +24,7 @@ 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

3 2

Nepal timezone spelling
by Phil Vandry Dec. 9, 2008

Dec. 9, 2008

Hello, I propose that the name of the Asia/Katmandu zone be changed to Asia/Kathmandu. Although Katmandu is an acceptable alternate spelling, I can attest, having recently returned from a holiday in Nepal, that it is hardly ever used. In fact, I saw no occurence at all of the spelling 'Katmandu' while inside the country. This patch keeps the Katmandu spelling for backward compatibility. After trying Asia/Kathmandu and then grepping the whole database for Kathmandu, I nearly concluded that this timezone definition was missing from the database before finally finding it under the alternate spelling! -Phil --- asia.orig 2008-10-08 08:35:57.000000000 -0400 +++ asia 2008-12-04 16:05:36.000000000 -0500 @@ -1474,7 +1474,7 @@ # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Katmandu 5:41:16 - LMT 1920 +Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:30 - IST 1986 5:45 - NPT # Nepal Time --- backward.orig 2008-09-09 22:33:26.000000000 -0400 +++ backward 2008-12-04 16:05:28.000000000 -0500 @@ -24,6 +24,7 @@ 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

2 1

Re: zdump loop problem
by Robbin Kawabata Dec. 8, 2008

Dec. 8, 2008

I ran ado's fix against all the timezones, and got good results. This is the diff: *** zdump_loop.c Tue Dec 2 11:17:01 2008 --- zdump_fix_ado.c Tue Dec 2 12:49:05 2008 *************** *** 312,322 **** (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); --- 312,320 ---- (void) strncpy(buf, abbr(&tm), sizeof (buf) - 1); } for (;;) { ! if (t >= cuthitime || t >= cuthitime - SECSPERHOUR * 12) break; newt = t + SECSPERHOUR * 12; if (newt <= t) break; newtmp = localtime(&newt); However, isn't the check for "if (newt <= t) break" no longer needed? ----- Begin Forwarded Message ----- Date: Mon, 01 Dec 2008 16:21:00 -0500 From: "Olson, Arthur David (NIH/NCI) [E]" <olsona(a)dc37a.nci.nih.gov> Subject: Re: zdump loop problem To: tz(a)lecserver.nci.nih.gov Cc: Andreas Radke <a.radke(a)arcor.de> So...in the real world, does changing the zic.c lines reading... if (t >= cuthitime) break; newt = t + SECSPERHOUR * 12; if (newt >= cuthitime) break; ...to read... if (t >= cuthitime || t >= cuthitime - SECSPERHOUR * 12) break; newt = t + SECSPERHOUR * 12; ...result in working code? I'd particularly appreciate feedback from Andreas Radke or other ArchLinux users. ----- End Forwarded Message -----

1 0

FW: Time Zone naming
by Olson, Arthur David (NIH/NCI) [E] Dec. 8, 2008

Dec. 8, 2008

I'm forwarding this message from Martin Barnes, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Martin Barnes [mailto:barnes@yahoo-inc.com] Sent: Friday, November 28, 2008 11:48 To: tz(a)lecserver.nci.nih.gov Subject: Time Zone naming I have a question related to the accepted standard for expressing the "Olsen" name where multiple zones exhibit the same "behaviour" in terms of belonging to the same country, having the same UTC offset and exactly the same DST rules. For example, it appears that all clocks within all locations within Argentina will have the same time all year round. The 12 zones reveal the same behaviour. The same is true of China and a number of other countries. I have been aware of the concept of a "consolidated" or "preferred" time zone which is a combined zone that takes the name of the most important location (eg. "America/Buenos_Aires" in the case of Argentina) Do these combined "super" zones exist? If so, is there information available that indicates how the individual zones roll up? My enquiry relates to a need to provide information that can identify the correct timezone for every place (city, postcode, county, state, etc etc) on earth via a back-end mapping service that calculates the spatial relationship between the place coordinate and the timezone boundary. I am looking to build up an accurate timezone boundary map essentially using existing map objects as building blocks. Many thanks -Martin Barnes ______________________ GeoData Manager Yahoo! Geo Technologies Geo Informatics team London

3 6

Cuba 2004-2006
by hsv＠tbbs.net Dec. 7, 2008

Dec. 7, 2008

This looks queer: 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 I take the foregoing for something like this: ... 2003 Apr Sun>=1 0:00s 1:00 D 2003 Oct lastSun 0:00s 0 S 2004 Apr Sun>=1 0:00s 1:00 D 2005 Apr Sun>=1 0:00s 1:00 D 2006 Apr Sun>=1 0:00s 1:00 D 2006 Oct lastSun 0:00s 0 S ... but at those Aprils in 2005 and 2006 there is no real shift. Is this right?

1 0

Western Samoa may implement Daylight Saving Time in 2009
by Alexander Krivenyshev Dec. 7, 2008

Dec. 7, 2008

The Samoa government (Western Samoa) may implement DST on the first Sunday of October 2009 (October 4, 2009) until the last Sunday of March 2010 (March 28, 2010). Selected Committee reports to Cabinet on Daylight Saving Time", Government of Samoa: http://www.govt.ws/pr_article.cfm?pr_id=560 or http://www.worldtimezone.com/dst_news/dst_news_samoa01.html Alexander Krivenyshev, http://www.worldtimezone.com/dst_news/ New York, NY

1 0

FW: Incorrect time zone abbreviations for Indonesia
by Olson, Arthur David (NIH/NCI) [E] Dec. 5, 2008

Dec. 5, 2008

I'm forwarding this message from Jason Grimes, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. Note that time zone abbreviations are consistently abbreviations of the English-language names of time zones. --ado -----Original Message----- From: Jason Grimes [mailto:jg@proz.com] Sent: Wednesday, November 19, 2008 12:23 To: tz(a)lecserver.nci.nih.gov Cc: Jason Grimes Subject: Incorrect time zone abbreviations for Indonesia Dear time zone data maintainers, I'm a developer at ProZ.com, a website for human language translators. One of our users has reported that the time zone names for the time zones in Indonesia, specifically Asia/Jakarta, Asia/Pontianak, Asia/Makassar, and Asia/Jayapura, are incorrect in the current time zone data. According to her, and to the following references, it appears that these time zone abbreviations should be updated as follows: ID offset current new Asia/Jakarta UTC+7 WIT WIB (Waktu Indonesia Barat) Asia/Pontianak UTC+7 WIT WIB (Waktu Indonesia Barat) Asia/Makassar UTC+8 CIT WITA (Waktu Indonesia Tengah) Asia/Jayapura UTC+9 EIT WIT (Waktu Indonesia Timur) References: http://time.kim.lipi.go.id/ http://www.statoids.com/tid.html I noticed a similar bug report from 2005 but I was unable to find any resolution: http://article.gmane.org/gmane.linux.debian.devel.glibc/12741/match=indo nesia I hope this gives enough information to update these time zone names. Thanks to all of you who help to maintain this valuable resource. Best regards, Jason Grimes

2 1

Nepal timezone spelling
by Phil Vandry Dec. 4, 2008

Dec. 4, 2008

Hello, I propose that the name of the Asia/Katmandu zone be changed to Asia/Kathmandu. Although Katmandu is an acceptable alternate spelling, I can attest, having recently returned from a holiday in Nepal, that it is hardly ever used. In fact, I saw no occurence at all of the spelling 'Katmandu' while inside the country. This patch keeps the Katmandu spelling for backward compatibility. After trying Asia/Kathmandu and then grepping the whole database for Kathmandu, I nearly concluded that this timezone definition was missing from the database before finally finding it under the alternate spelling! -Phil --- asia.orig 2008-10-08 08:35:57.000000000 -0400 +++ asia 2008-12-04 16:05:36.000000000 -0500 @@ -1474,7 +1474,7 @@ # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Katmandu 5:41:16 - LMT 1920 +Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:30 - IST 1986 5:45 - NPT # Nepal Time --- backward.orig 2008-09-09 22:33:26.000000000 -0400 +++ backward 2008-12-04 16:05:28.000000000 -0500 @@ -24,6 +24,7 @@ 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

1 0

Posix Timezone format
by Louis Guindon Dec. 2, 2008

Dec. 2, 2008

Hi All, My goal is to provide a user interface showing the information derived from the TZ zone name. Based on the selected TZ zone name by the user, I will assign the corresponding POSIX time zone string to the Linux /tmp/TZ file. This way the local time will show up properly for the user. However, I am having difficulty to find a reliable source for POSIX time zone string representation for each defined time zone in the Olson database. Also, the Olson database is changing many times a year which is making it difficult to hardcode anything in advance. I am sure that my problem already encountered by someone on this mailing list and I am wandering if there is a way to query the current version of the Olson database with some tool to return the related POSIX representation for the requested time zone. I don't know if there is an alternative way, but I am also wandering if the TZ time zone name can used directly without going through the POSIX representation of the time zone. Note: POSIX time zone representation for me is the following. The TZ zone name America/Los_angeles is represented as PST8PDT,M3.2.0,M11.1.0. Regards, Louis Guindon PMC-Sierra Senior System Design Engineer

4 5

Re: zdump loop problem
by Olson, Arthur David (NIH/NCI) [E] Dec. 2, 2008

Dec. 2, 2008

So...in the real world, does changing the zic.c lines reading... if (t >= cuthitime) break; newt = t + SECSPERHOUR * 12; if (newt >= cuthitime) break; ...to read... if (t >= cuthitime || t >= cuthitime - SECSPERHOUR * 12) break; newt = t + SECSPERHOUR * 12; ...result in working code? I'd particularly appreciate feedback from Andreas Radke or other ArchLinux users. --ado

2 1

Time WRONG for Australia\Perth
by Vera Tong Dec. 2, 2008

Dec. 2, 2008

Hi, Reckon the Time's wrong for Australia\Perth, The place is now in DST, and the time should be GMT+9 Thanks, ____________________________________________ Vera Tong Maximo System Manager Tungsten Group Pty Ltd Level 3, 100 Dorcas Street, South Melbourne, Victoria, 3207 Phone +61 3 9697 0022 Fax +61 3 9686 7999 Mobile +61 439 345 025 www.tungstengroup.com <http://www.tungstengroup.com/> Tungsten is a division of Programmed Maintenance Services Limited. This e-mail (and any attachments to this e-mail) is for the exclusive use of the person, firm or corporation to which it is addressed and may contain information that by law is privileged, confidential or protected by copyright. If you are not the intended recipient or the person responsible for the delivering of this e-mail to the intended recipient, you are notified that any use, disclosure, distribution, printing or copying of this e-mail transmission is prohibited by law and that the contents must be kept strictly confidential. If you have received this e-mail in error, kindly notify us immediately or respond to the sender by return e-mail. The original of this e-mail must be destroyed. P Please consider the environment before printing this email and any attachments.

1 0

Time Zone naming
by Martin Barnes Nov. 28, 2008

Nov. 28, 2008

I have a question related to the accepted standard for expressing the "Olsen" name where multiple zones exhibit the same "behaviour" in terms of belonging to the same country, having the same UTC offset and exactly the same DST rules. For example, it appears that all clocks within all locations within Argentina will have the same time all year round. The 12 zones reveal the same behaviour. The same is true of China and a number of other countries. I have been aware of the concept of a "consolidated" or "preferred" time zone which is a combined zone that takes the name of the most important location (eg. "America/Buenos_Aires" in the case of Argentina) Do these combined "super" zones exist? If so, is there information available that indicates how the individual zones roll up? My enquiry relates to a need to provide information that can identify the correct timezone for every place (city, postcode, county, state, etc etc) on earth via a back-end mapping service that calculates the spatial relationship between the place coordinate and the timezone boundary. I am looking to build up an accurate timezone boundary map essentially using existing map objects as building blocks. Many thanks -Martin Barnes ______________________ GeoData Manager Yahoo! Geo Technologies Geo Informatics team London

1 0

zdump loop problem
by Robbin Kawabata Nov. 25, 2008

Nov. 25, 2008

This sounds like a problem we encountered too. zdump.c uses behavior of integer overflow on L.358 to detect when newt has reached or exceeded the maximum time_t value. When newt exceeds the maximum time_t value from L.356, it overflows to a negative number, so the L.358 check for newt less than t succeeds. However according to the C Standard, the behavior of integer overflow is undefined (see below). The Sun Studio 11 compiler with -O flag optimizes L.358 out, because it detects the check is not needed, because for the valid range of time_t, newt will never be > t, since from L.355 newt is t plus a positive number. With L.358 optimized out, the for loop at L.352 executes infinitely. zdump.c: ... 249 time_t t; 250 time_t newt; ... 352 for ( ; ; ) { 353 if (t >= cuthitime) 354 break; 355 newt = t + SECSPERHOUR * 12; <-- 356 if (newt >= cuthitime) 357 break; 358 if (newt <= t) <-- 359 break; 360 newtmp = localtime(&newt); ... 376 t = newt; 377 tm = newtm; 378 tmp = newtmp; 379 } A possible fix is to instead check whether t plus delta (delta = SECSPERHOUR * 12) is greater than the maximum time_t: (time + delta) > max_time_t or: time > max_time_t - delta /* avoids time+delta overflow */ ------- zdump.c ------- @@ -314,11 +314,12 @@ for (;;) { if (t >= cuthitime) break; + /* check if newt will overrun maximum time_t value */ + if (t > LONG_MAX - (SECSPERHOUR * 12)) + break; newt = t + SECSPERHOUR * 12; if (newt >= cuthitime) break; - if (newt <= t) - break; newtmp = localtime(&newt); if (newtmp != NULL) newtm = *newtmp; The C Standard says (for signed integer): ISO/IEC 9899:1999: 6.5 p5: If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined. 3.4.3 p3: EXAMPLE: An example of undefined behavior is the behavior on integer overflow. > Date: Mon, 24 Nov 2008 09:09:13 -0500 > From: "Olson, Arthur David (NIH/NCI) [E]" <olsona(a)dc37a.nci.nih.gov> > Subject: FW: mail to tz list bounced > To: tz(a)lecserver.nci.nih.gov > Cc: Andreas Radke <a.radke(a)arcor.de> > > I'm forwarding this message from Andreas Radke; while Andreas is on the > time zone mailing list, the message bounced when he tried to send it > directly. > > --ado > > Datum: Wed, 19 Nov 2008 21:47:05 +0100 > Von: Andreas Radke <a.radke(a)arcor.de> > An: tz(a)lecserver.nci.nih.gov > Betreff: optimization -O2 broken? > > I'm the ArchLinux package maintainer for tzdata. We are using gcc > 4.3.2/glibc2.8- We have run into a small problem with compiler > optimizations. > > Using our default CFLAGS="-march=i686 -mtune=generic -O2 -pipe" the > zdump binary is built in broken way on i686 architecture. I have to > apply -O1 to make zdump work. See our bugreport: > http://bugs.archlinux.org/task/11947 > > I could confirm this when running zdump -v EUROPE/BERLIN it stuck after > two printing first two lines. > > x86_64 architecture doesn't seem to be affected. Any idea why this > happens and how to fix it? > > -Andy >

4 6

Running tzcode under Windows / C++ .NET
by Gerber, Oliver Nov. 25, 2008

Nov. 25, 2008

Hello all, we are using the TZ database on an embedded device. As the system has no standard operating system (only a small proprietary MicroKernel) and is not very powerful, we cannot use the TZ data "as is" on the device. Instead of this, we create text files from the TZ data for the countries and the time range we need on our system. The application that is used to create these files, is written in C++ .NET (because our whole development and deployment processes are done on Windows-based machines). Currently I'm using a Linux machine to compile/make the code from tzcode*.tar.gz and to create the binary tzfiles. These binary files are then parsed by the application mentioned above. Is there any possibility to compile the tzcode under Windows (especially Visual Studio 2005/2008) so that we could create our text files automatically using only the tzcode*.tar.gz and tzdata*.tar.gz archives? I'd appreciate any help or hints. Best regards, Oliver Oliver Gerber Diplom-Informatiker Software Engineer Cardinal Health Research Services ph: +49 931 4972 276 | fax: +49 931 4972 62276 oliver.gerber(a)cardinalhealth.com <mailto:moliver.gerber@cardinalhealth.com> www.cardinalhealth.com/researchservices Cardinal Health Germany 234 GmbH Leibnizstr. 7 97204 Hoechberg, Germany District Court Wuerzburg HRB 7004 General Management: Ralf Lother, Paul ter Grote, Ellen de Jager-Satter, Rudy Mareel, Linda Harty DISCLAIMER: This information and any attachments contained in this email message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, forwarding, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email, and delete the original message immediately.

3 3

FW: mail to tz list bounced
by Olson, Arthur David (NIH/NCI) [E] Nov. 24, 2008

Nov. 24, 2008

I'm forwarding this message from Andreas Radke; while Andreas is on the time zone mailing list, the message bounced when he tried to send it directly. --ado Datum: Wed, 19 Nov 2008 21:47:05 +0100 Von: Andreas Radke <a.radke(a)arcor.de> An: tz(a)lecserver.nci.nih.gov Betreff: optimization -O2 broken? I'm the ArchLinux package maintainer for tzdata. We are using gcc 4.3.2/glibc2.8- We have run into a small problem with compiler optimizations. Using our default CFLAGS="-march=i686 -mtune=generic -O2 -pipe" the zdump binary is built in broken way on i686 architecture. I have to apply -O1 to make zdump work. See our bugreport: http://bugs.archlinux.org/task/11947 I could confirm this when running zdump -v EUROPE/BERLIN it stuck after two printing first two lines. x86_64 architecture doesn't seem to be affected. Any idea why this happens and how to fix it? -Andy

1 0

Incorrect time zone abbreviations for Indonesia
by Jason Grimes Nov. 19, 2008

Nov. 19, 2008

Dear time zone data maintainers, I'm a developer at ProZ.com, a website for human language translators. One of our users has reported that the time zone names for the time zones in Indonesia, specifically Asia/Jakarta, Asia/Pontianak, Asia/Makassar, and Asia/Jayapura, are incorrect in the current time zone data. According to her, and to the following references, it appears that these time zone abbreviations should be updated as follows: ID offset current new Asia/Jakarta UTC+7 WIT WIB (Waktu Indonesia Barat) Asia/Pontianak UTC+7 WIT WIB (Waktu Indonesia Barat) Asia/Makassar UTC+8 CIT WITA (Waktu Indonesia Tengah) Asia/Jayapura UTC+9 EIT WIT (Waktu Indonesia Timur) References: http://time.kim.lipi.go.id/ http://www.statoids.com/tid.html I noticed a similar bug report from 2005 but I was unable to find any resolution: http://article.gmane.org/gmane.linux.debian.devel.glibc/12741/match=indones… I hope this gives enough information to update these time zone names. Thanks to all of you who help to maintain this valuable resource. Best regards, Jason Grimes

1 0

Linux patches for Argentina 2008 DST rules
by Fang Lu Nov. 18, 2008

Nov. 18, 2008

Hello, all: Are there any Linux (SLED10, RHEL5 and Ubuntu) patches that I can download for the latest Argentina 2008 DST rules?. If so, could you please point me to the correct links? Thanks in advance, Florence

2 1

Kazakhstan historic time
by Jesper Norgaard Welen Nov. 16, 2008

Nov. 16, 2008

Recently I was checking the timezone map from Eric Muller (Adobe) and came to the conclusion that he had the Kostanai (or Kustanai) area as part of the Qyzylorda time zone although they are not even adjacent, but still on comparatively the same longitude. The area of Kostanai I assumed was part of the main area of Kazakhstan represented by Asia/Almaty. I am not sure where Eric got his information from, but the story doesn't end here. I found a russian astronomical page HYPERLINK "http://zaytsev.com/forum/viewtopic.php?p=10571"http://zaytsev.com/forum/vie wtopic.php?p=10571 that raises the issue that this so-called ZET 8 time is wrong. Here is a translation from Google of the original russian article === Quote begin === Thu Apr 17, 2008 4:14 pm Posted: Thu Apr 17, 2008 4:14 pm ZET Post: Temporary amendments to the ZET ---------------------------------------------------------------------------- ---- Help solve the dilemma with the definition of a temporary correction. I was born in Kostanai area in November 1976. Some astrological programs, including ZET 8, provide a temporary amendment +4 GMT. At the same time, Moscow is +3 GMT. This means that the difference with Moscow entire 1 hour. But it never was. The difference has always been 2 hours. And parents attest to the fact that the difference with Moscow has always been 2 hours. The program ZET 8 geo gives a sharp change of a temporary amendment to a very long period: 01 Jan 0001 00:00 LMT +00:00:00 01 Jan 0001 00:00 LMT +00:00:00 02 May 1924 00:00 +04:00:00 02 May 1924 00:00 +04:00:00 21 Jun 1930 00:00 +05:00:00 21 Jun 1930 00:00 +05:00:00 01 Dec 1956 00:00 +04:00:00 01 Dec 1956 00:00 +04:00:00 01 Apr 1981 00:00 +05:00:00 01 Apr 1981 00:00 +05:00:00 In fact this change temporary amendment in 1956 is due to the change of time zones. I can not find any information about the change of time zones in 1956, although the time change occurred not only in the Kostanai region. This tool, please, if anyone has information about this change of temporary amendments of 1956, which legislation has been done? Even familiar to consultants not able to answer that question. Do not mistake that caused even if Spravochnikov coordinates of the first edition of Cities and temporary amendments and continually reissued by different authors ... Let us find the truth in this matter, as he stubbornly insist that the time of my birth at +1 GMT differs from the time in the program and is +5 GMT. I think if I would have the rights to many "go" horoscopes ... But it is still "a friend of Plato me, but the truth is more expensive ..." === Quote end === I guess you can't expect miracles from an automated translation. What I understand from the email is that this person claims to have been born in Kostanai in 1976 and that time there since has "always" been GMT+5 or rather Moscow time plus 2 hours. This does not correspond to the Asia/Almaty time zone but corresponds pretty well with the Asia/Qyzylorda time zone. The thread is not faultless for instance another person grabs a part of the World Time Explorer file Historic.txt and concludes that Astana was on GMT+5 from 1930 to 1991 while in fact the correct number is GMT+6 I might be exaggerated in assuming this is authoritative information (yet) but all the same perhaps readers of this mailing list have more information they can share. The mixture of Eric's map with the administrative regions however shows another difference that I can't explain, see the following map: HYPERLINK "http://www.worldtimeexplorer.com/Kustanai-2008-11-09.png"http://www.worldti meexplorer.com/Kustanai-2008-11-09.png The red borders are the time zones of his map. The black zones are the recent administrative regions, as we can also see on this wikipedia map of the Kostanai region: HYPERLINK "http://en.wikipedia.org/wiki/Image:Kost_obl.svg"http://en.wikipedia.org/wik i/Image:Kost_obl.svg but Eric's map contains a bite of the Astana area. In conclusion if the Kustanai/Kostanai region has always been on Qyzylorda time, we don't have to do anything to Kazakhstan timezones but it would be good to document this on the notes to the Asia/Qyzylorda time zone. Whether the Kustanai region covers modern-time administrative area or not will then be very important to the maps of Eric and WTE, but not directly to the tz database. Also I think it would be good to add all current administrative regions of Kazakhstan to the notes of the asia file. Any comments are welcome. - Jesper Nørgaard Welen No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.9.4 - Release Date: 2008-11-14 0:00

1 0

America/Resolute
by Chris Walton Nov. 14, 2008

Nov. 14, 2008

Not that anybody asked... but I thought I would provide an update on America/Resolute. Some of you may remember that in 2006, the small community of Resolute a.k.a. "Resolute Bay" in Canada's arctic stopped the biannual practice of changing the clocks. In March of 2007 I initiated the creation of a new Canadian zone named "America/Resolute" with a fixed time of "UTC-5". The only web reference that I ever came across (other than my own postings) was this: http://www.nnsl.com/frames/newspapers/2006-11/nov13_06none.html Since there has been no recent documentation, legislation, news reports, or any other information on this subject, I decided to place a another call to the Resolute "hamlet office" last week to get an update. I was able to confirm that Resolute is still stuck on UTC-5. Thus the current information in the TZ database remains correct. I will mention, however, that 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)". I don't think anybody expects the TZ database to accommodate for this... as long as the offset from UTC is correct. I did notice today that the entry for Resolute in the zone.tab says "Eastern Time - Resolute, Nunavut". To be consistent with other Canadian zones that don't observe daylight saving time, it should probably say "Eastern Standard Time - Resolute, Nunavut". -chris -----Original Message----- From: Chris Walton Sent: March 14, 2007 11:03 AM To: 'tz(a)elsie.nci.nih.gov' Subject: RE: proposed tz patches for Cuba, Mongolia, Turkey, Resolute, Indonesia A couple of weeks ago I reported that "Resolute" on Cornwallis Island in Nunavut Canada did not change its clocks on October 29/2006. I only had one source of information. http://www.nnsl.com/frames/newspapers/2006-11/nov13_06none.html Today I phoned the "hamlet office" to find out what Resolute was doing with its clocks. 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). He was not sure whether to refer to the local time as "Eastern Time" or "Central Time" but we did a quick time check comparing his clock vs my clock and I was able to confirm that Resolute is currently running on UTC-5. The implication is that Resolute has been on UTC-5 (Eastern Standard Time or Central Daylight Time) since April 2/2006. I was also told that the hamlet council has not officially announced what will happen next fall. Apparently there was confusion for residents when the time did not change last October... specifically with respect to television schedules. 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. -chris

1 0

Re: Posix Timezone format
by HJWOUDENBERG＠aol.com Nov. 14, 2008

Nov. 14, 2008

I have developed a time zone systems that uses ISO-3166 AnyDateTime CREATED BOLD DARING NEW TECHNIQUES. The results had amazing results: · Incredible speed. · Incredible capabilities. · Incredible simplicity. The results are exciting, but striving for perfection required tremendous tenacity but was very satisfying. AnyDateTime¾USES INTERNATIONAL STANDARDS. Date/time format conversion. Uses the ISO-8601 (International Organization for Standardization) date/time formats. The Internet XML requires the use of this format. · Converts North America formats 06/18/2008 01pm to the common world use of 18.06.2008 13:00 or the international standard 2008-06-18T13:00:00 · Features that are unique to international ISO-8601 standard are implemented into local date/time formats. Therefore, an international date/time can be converted to a local date/time and back to the international date/time. Date/time time-zone conversion. Uses the ISO-3166 location codes for countries and states. · The same codes used to mail letters are used to converting US EST (EDT) to CST (CDT), MST (MDT), PST (PDT), AST (ADT) or HST or anywhere else in the world. Uses the IATA city codes (International Air Transport Association). · The same 3 letter code on your airline luggage can be used for time zone conversion and currency conversion. Date/time manipulation. Uses the ISO-8601 durations. · The ISO-8601 duration “PnYnMnDTnHnMnS” is used for working with years, months, days, hours, minutes, seconds or fractions of time regardless of MM/DD/YYYY, DD.MM.YYYY or YYYY-MM-DD format. Adding/subtracting date/time Setting date/time to a specific date/time, like the start and ending of daylight. Getting date/time for different formats like “6/18/2008 1pm” or “2008-01-18 13:00” Comparing different formats equal “06/18/2008 6pm-05;00” = “2008-06-19 01:00+02:00” Finding the difference in years, hours, days, hours, minutes, seconds or in combinations of elements. · Created a new “Event Algebra” by expanding the ISO-8601 durations “=±P=±nY=±nM=±nD=±T=±nH=±nM=±nS=±.nF”. The event of the start of daylight saving time is: The 3rd month, the 2cd week, on the 1st day of the week at 2am The formula =03m14d-1dwT=2h This is much simpler than the Microsoft’s Excel or Visual Basic methods. Currency conversion. Global selling requires currency conversion as well as time conversions. The same way is sued for currency conversion as is used for time zone conversion. AnyDateTime UNIQUE CREATIONS. Created the fastest time zone conversion routine in the world. For the first time every, computers can do simultaneous mixed-radix arithmetic. If it is plugged into the C/C++ conversions routines or IBM’s durations routines they run 2.75 time faster. Created the fastest date/time validation routines in the world. The checking for 30 and 31 day months and leap years is so fast it is almost un-measurable for a million date/time checks, so it is always on. Java date/time check is so slow it permits it to be turned off for speed. IBM’s date/time almost doubles the CPU usage if date/time is checked. C/C++ requires programmers to write their own 30 day month check else it converts 2008-06-31 to 2008-07-01 without error indicator. Created “Event Algebra” that simplifies event calculation and provides a standard method for event calculation. The ISO-8601 duration “PnYnMnDTnHnMnS” has been expanded to create “Event Algebra”. Created an Internet auto synchronization for client table update. When North America changed the daylight savings time, your computer was updated automatically over the Internet. However, companies doing business over around the world need the time zones of everywhere in the world. Those nice time zone lines on maps or computer screens are no more than approximations and don’t reflect daylight savings time. The advantages of a local service: · A local service program can do in minutes what takes days using a Web-service. · The auto-synchronization feature give local services the same features as Web-services, it updates the tables on the client computer without any manual intervention. The risks with Web-services: · Some applications kill Internet performance, so all other applications suffers. · The potential for gouging by application service providers (ASP). · No control over ASP performance or quality. The disadvantage of other local services: · Other date/time routines use the “tz.database” that must be compiled on the client’s computer and requires manually intervention to put into production. AnyDateTime date/time data type has incredible capabilities. Herman J Woudenberg The world’s largest date range has a worlds largest date range of 2 million years (±1 million –1 year). UNIX/LINUX JAVA & C/C++ have a date range of 68 years, 1970 to 2038. ANSI COBOL-90 has a date range from 1601 to 9999. IBM Power PC computer has a date range from 1483 to 9999. Microsoft .NET (Vista) has a date range from 0001 to 9999. Microsoft Com (XP) has a date range from 1600 to 9999. Oracle has a date range from 4500BC to 9999 AD. The world’s smallest time precision as small as femto-seconds, 15 fractional digits_[i]_ (aoldb://mail/write/template.htm#_edn1) . UNIX and C only have whole seconds, no fractions of seconds. Java has milliseconds, 3 fractional digits. IBM has up to microseconds, 6 fractions digits. Microsoft has 100 nanoseconds, about 7 fractional digits. Oracle has up to 9 fractions digits. Network Time Protocol has 10 fractional digits. ____________________________________ _[i]_ (aoldb://mail/write/template.htm#_ednref1) Fractions of seconds. Milli-second (ms or msec) is one thousandth of a second (.999 or 10-3). It is used for read/write time of hard disk or CD-ROM and packet travel time on the Internet. Micro-second (us or Greek letter mu plus s) is one millionth (.999_999 or 10-6) of a second. It is used to measure the speed of CPUs. Nano-secnd (ns or nsec) is one billionth (.999_999_999 or 10-9) of a second. It is used for read/write time of random access memory (RAM). Pico-second is one trillionth (.999_999_999_999 or 10-12) of a second, or one millionth of a microsecond. It is used by the Net Work Time Protocol clock. Femto-second is one millionth of a nanosecond (.999_999_999_999_999 or 10-15) of a second. It is used in laser technology. Atto-second is one quintillionth (.999_999_999_999_999_999 or 10-18) of a second. It is a used in photon research. **************Get the Moviefone Toolbar. Showtimes, theaters, movie news & more!(http://pr.atwola.com/promoclk/100000075x1212774565x1200812037/aol?red… p://toolbar.aol.com/moviefone/download.html?ncid=emlcntusdown00000001)

1 0