- tz - lists.iana.org

FW: Web page updates
by Olson, Arthur David (NIH/NCI) Aug. 11, 2005

Aug. 11, 2005

Frank Vance is not on the time zone mailing list (at least not at the address below); direct replies appropriately. --ado -----Original Message----- From: Frank Vance [mailto:frankvance@mindspring.com] Sent: Wednesday, August 10, 2005 11:45 AM To: tz(a)lecserver.nci.nih.gov Subject: Web page updates tz-art.html: The link http://www.videoflicks.com/VF2/1035/1035893.ihtml should be changed to: http://www.videoflicks.com/titles/1035/1035893.htm tz-links.htm: The link http://www.astrologyhouse.co.nz/timechanges.htm does not exist anymore, and I can not find a relocated page at the web site. The link http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2 does not exist anymore, and I can not find a relocated page at the web site. The link http://www.nationalatlas.gov/timeznm.html does not exist anymore. http://nationalatlas.gov/mld/timeznp.html seems to be a suitable replacement.

1 0

Web page updates
by Frank Vance Aug. 10, 2005

Aug. 10, 2005

tz-art.html: The link http://www.videoflicks.com/VF2/1035/1035893.ihtml should be changed to: http://www.videoflicks.com/titles/1035/1035893.htm tz-links.htm: The link http://www.astrologyhouse.co.nz/timechanges.htm does not exist anymore, and I can not find a relocated page at the web site. The link http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2 does not exist anymore, and I can not find a relocated page at the web site. The link http://www.nationalatlas.gov/timeznm.html does not exist anymore. http://nationalatlas.gov/mld/timeznp.html seems to be a suitable replacement.

1 0

FW: Request from CLDR committee
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

Mark Davis is not on the time zone mailing list (at least not at the address below); direct replies appropriately. --ado ----- Original Message ----- From: "Mark Davis" <mark.davis(a)icu-project.org> To: "Tz (tz(a)elsie.nci.nih.gov)" <tz(a)lecserver.nci.nih.gov> Cc: "Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> Sent: Tuesday, August 09, 2005 07:28 Subject: Request from CLDR committee The CLDR technical committee has been looking at issues that have come up in connection with timezones, and have the following requests of the TZ group. Background. As discussed previously on this list, the CLDR project supplies localizations for timezone identifiers, based on the TZ IDs from the TZ database. The localizations can either be explicit strings, or if unavailable, use the translated country name (where a country has only a single timezone) or fall back to the last field of the TZID and the translated country name. Thus in German: America/Havana => "Kuba" Europe/Moscow => "Moskau (Russische Föderation)" America/Los_Angeles => "Los Angeles (Vereinigte Staaten)" The process is somewhat more complicated than this description, but this provides the gist. For other examples, see http://unicode.org/cldr/data/common/test/ with different locales. (BTW, a corrigendum was issued for the GMT problem raised earlier; see http://unicode.org/cldr/corrigenda.html) Requests. 1. Missing Country Codes. There are two missing ISO country codes. While these are uninhabited rocks, they should be added according to Theory, which says: " Include at least one location per time zone rule set per country. One such location is enough. Use ISO 3166 (see the file iso3166.tab) to help decide whether something is a country. " There are also good, practical reasons to do this; an implementation that maps from country codes to sets of zones needs to have some value for all ISO country codes. The two ISO codes are: HM 53 06 S, 72 31 E Heard Island and McDonald Islands BV 54 26 S, 3 24 E Bouvet Island (locations are from http://www.cia.gov/cia/publications/factbook/geos/bv.html http://www.cia.gov/cia/publications/factbook/geos/hm.html ) Suggested changes: To zone.tab, add HM -5306+7231 Pacific/Heard BV -5426+0324 Atlantic/Bouvet To antarctica, add Zone Atlantic/Bouvet 0:00 - GMT Zone Pacific/Heard 5:00 - GMT 2. Enabling Canonical IDs The Link commands in the database establish equivalence classes between TZIDs (aka "location names"). For an implementation like CLDR, it is important that there be a completely stable canonical TZID that represents any of those equivalents. Based on feedback from this list, we chose it to be: a) the TZID in zone.tab as of 2004a, or b) any new TZID in a later version of zone.tab that is not equivalent to a TZID introduced in an earlier version. That is, we use America/Buenos_Aires since it was in 2004a, and America/Argentina/Tucuman since it was introduced later. One dependency we have is that the last field in the canonical ID be unique. That is, we can't have both a Europe/London and an America/London. Now, if the TZ database ever added a TZID that was not unique in this sense, we could add our own canonical ID outside of the TZ database, but that is clearly not our preference, not at all. This appears to be the practice in the TZ database, as evidenced by the following in southamerica: # Bahia (BA) # There are too many Salvadors elsewhere, so use America/Bahia instead # of America/Salvador. We also depend on the feature that every equivalence class (except Etc/...) has exactly one member in zone.tab. To avoid having to hack around problems in the future, we would like this to be captured in Theory as requirements for the construction of future IDs. This is in no way a functional restriction, just on the choice of names. Thus, we propose the addition of something like the following to the "rules used for choosing location names" in Theory. All locations (the final field in a location name) must be unique. Thus one cannot have Europe/London and either America/London or America/Canada/London. Two location names that appear in zone.tab cannot be Linked together, either directly or through a chain of Links. Conversely, every location (except for those starting with "Etc") must be Linked to a location name in zone.tab. 3. Definitional Links. For the purpose of something like CLDR, it is important to separate out the *definitional* equivalents from the *incidental* equivalents (equivalencies that happen to be true for now, but could change in the future). You don't want to include two TZIDs in the same definitional equivalence class if they are ever different, or could be in the future, because then comparisons between TZIDs (as equivalent) could be true now, but fail in the future. After looking at the equivalence classes established by Link, it turns out that there are a few anomalies. Now, Theory says: " If all the clocks in a country's region have agreed since 1970, don't bother to include more than one location even if subregions' clocks disagreed before 1970. Otherwise these tables would become annoyingly large. " This makes a great deal of sense. After all, if we go back to when daylight savings started, then every location on earth (that didn't share a longitude with another location) would be a separate TZID. However, there are a small number of anomalous cases. List A below contains items that should be Linked, since they are always and will always be equivalent (as far as TZ calculations go). List B contains cases that have been the same since 1970, but are not Linked. So they appear to violate the condition above in Theory. Conversely, List C contains cases that clearly reference different locations, and thus before timezones were added, they had different offsets (sun time). So if the same criteria are applied as in List B, they would be unlinked. So we request that the items in List A be linked, and each of the pairs in List B and C be treated consistently: Option 1. Leave (or make) the pair Linked, and pick one item in each pair, and document that it is obsolete, and will never be unlinked from the other. Option 2. Leave (or make) the pair Unlinked. If it was previously Linked, then thus according to #2 above, one of the pair would be added to zone.tab. And add to Theory, under "rules used for choosing location names". As of version X, whenever two location names have been linked in the past, for stability they will remain linked forever. ============= List A. TZIDs that are not linked, but are the same 001 Etc/GMT 001 Etc/UTC 001 Etc/UCT -- not linked, identical List B. TZIDs that are not linked, are different locations, but are the same since 1970 AQ Antarctica/Mawson AQ Antarctica/Vostok -- same since 57 FM Pacific/Truk FM Pacific/Yap -- same since 70 GB Europe/Belfast GB Europe/London -- same since 68 ML Africa/Bamako ML Africa/Timbuktu -- same since 60 List C. TZIDs that are linked, but refer to different locations. (This was derived by inspection; if there are other cases of IDs that refer to different locations, please let us know.) AQ Antarctica/McMurdo AQ Antarctica/South_Pole -- linked, different places SJ Arctic/Longyearbyen SJ Atlantic/Jan_Mayen -- linked, different places US America/Denver US America/Shiprock -- linked, different places AR America/Argentina/Cordoba AR America/Rosario -- linked, different places AU Australia/Sydney AU Australia/Canberra -- linked, different places BR America/Rio_Branco BR America/Porto_Acre -- linked, different places BR Brazil/Acre ? IL Asia/Jerusalem IL Asia/Tel_Aviv -- linked, different places MD Europe/Chisinau MD Europe/Tiraspol -- linked, different places MX America/Tijuana MX America/Ensenada -- linked, different places US America/Indianapolis US America/Fort_Wayne -- linked, different places

1 0

RE: bug introduced in tzcode2005c
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

The infinite loop is caused by my failure to check for overflow; here's a proposed fix. --ado ------- localtime.c ------- *** /tmp/geta2299 Tue Aug 9 09:56:30 2005 --- /tmp/getb2299 Tue Aug 9 09:56:30 2005 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.95"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.96"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1616,1624 **** --- 1616,1628 ---- if (dir != 0) { if (t == lo) { ++t; + if (t <= lo) + return WRONG; ++lo; } else if (t == hi) { --t; + if (t >= hi) + return WRONG; --hi; } if (lo > hi)

1 0

FW: bug introduced in tzcode2005c
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

Todd C. Miller is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Todd C. Miller [mailto:Todd.Miller@courtesan.com] Sent: Monday, August 08, 2005 11:29 PM To: tz(a)lecserver.nci.nih.gov Subject: bug introduced in tzcode2005c A change in tzcode 2005c causes the following program on OpenBSD to loop forever. I've tracked it down to the change included at the end of this message. Previously:: $ ./mktime Timestamp is: -1 Date is: Thu Jan 1 00:59:59 1970 With tzcode 2005c and beyond it loops forever. #include <sys/types.h> #include <stdio.h> #include <time.h> #include <stdlib.h> /* * This small programm will consume 100% CPU and loops forever with * tzcode 2005c - 2005k. */ int main(int argc, char **argv) { time_t timet; struct tm tm; tm.tm_sec = 36; tm.tm_min = 5; tm.tm_hour = 23; tm.tm_mday = 31; tm.tm_mon = 11; tm.tm_year = 138; /* 2038 - 1900 */ tm.tm_isdst = 0; timet = mktime(&tm); printf("Timestamp is: %d\n", timet); printf("Date is: %s\n", ctime(&timet)); exit(0); } Here's the change that triggers it. --- tzcode2005b/localtime.c Mon Jan 10 07:19:41 2005 +++ tzcode2005c/localtime.c Mon Jan 17 16:36:15 2005 @@ -1441,10 +1436,11 @@ { register const struct state * sp; register int dir; - register int bits; register int i, j; register int saved_seconds; register long li; + register time_t lo; + register time_t hi; long y; time_t newt; time_t t; @@ -1518,28 +1514,49 @@ yourtm.tm_sec = 0; } /* - ** Divide the search space in half - ** (this works whether time_t is signed or unsigned). + ** Do a binary search (this works whatever time_t's type is). */ - bits = TYPE_BIT(time_t) - 1; - /* - ** If time_t is signed, then 0 is just above the median, - ** assuming two's complement arithmetic. - ** If time_t is unsigned, then (1 << bits) is just above the median. - */ - t = TYPE_SIGNED(time_t) ? 0 : (((unsigned long) 1) << bits); + if (!TYPE_SIGNED(time_t)) { + lo = 0; + hi = lo - 1; + } else if (!TYPE_INTEGRAL(time_t)) { + if (sizeof(time_t) > sizeof(float)) + hi = (time_t) DBL_MAX; + else hi = (time_t) FLT_MAX; + lo = -hi; + } else { + lo = 1; + for (i = 0; i < (int) TYPE_BIT(time_t) - 1; ++i) + lo *= 2; + hi = -(lo + 1); + } for ( ; ; ) { - if ((*funcp)(&t, offset, &mytm) == NULL) - return WRONG; /* XXX probably wrong */ - dir = tmcomp(&mytm, &yourtm); + t = lo / 2 + hi / 2; + if (t < lo) + t = lo; + else if (t > hi) + t = hi; + if ((*funcp)(&t, offset, &mytm) == NULL) { + /* + ** Assume that t is too extreme to be represented in + ** a struct tm; arrange things so that it is less + ** extreme on the next pass. + */ + dir = (t > 0) ? 1 : -1; + } else dir = tmcomp(&mytm, &yourtm); if (dir != 0) { - if (bits-- < 0) + if (t == lo) { + ++t; + ++lo; + } else if (t == hi) { + --t; + --hi; + } + if (lo > hi) return WRONG; - if (bits < 0) - --t; /* may be needed if new t is minimal */ - else if (dir > 0) - t -= ((long) 1) << bits; - else t += ((long) 1) << bits; + if (dir > 0) + hi = t; + else lo = t; continue; } if (yourtm.tm_isdst < 0 || mytm.tm_isdst == yourtm.tm_isdst)

1 0

bug introduced in tzcode2005c
by Todd C. Miller Aug. 9, 2005

Aug. 9, 2005

A change in tzcode 2005c causes the following program on OpenBSD to loop forever. I've tracked it down to the change included at the end of this message. Previously:: $ ./mktime Timestamp is: -1 Date is: Thu Jan 1 00:59:59 1970 With tzcode 2005c and beyond it loops forever. #include <sys/types.h> #include <stdio.h> #include <time.h> #include <stdlib.h> /* * This small programm will consume 100% CPU and loops forever with * tzcode 2005c - 2005k. */ int main(int argc, char **argv) { time_t timet; struct tm tm; tm.tm_sec = 36; tm.tm_min = 5; tm.tm_hour = 23; tm.tm_mday = 31; tm.tm_mon = 11; tm.tm_year = 138; /* 2038 - 1900 */ tm.tm_isdst = 0; timet = mktime(&tm); printf("Timestamp is: %d\n", timet); printf("Date is: %s\n", ctime(&timet)); exit(0); } Here's the change that triggers it. --- tzcode2005b/localtime.c Mon Jan 10 07:19:41 2005 +++ tzcode2005c/localtime.c Mon Jan 17 16:36:15 2005 @@ -1441,10 +1436,11 @@ { register const struct state * sp; register int dir; - register int bits; register int i, j; register int saved_seconds; register long li; + register time_t lo; + register time_t hi; long y; time_t newt; time_t t; @@ -1518,28 +1514,49 @@ yourtm.tm_sec = 0; } /* - ** Divide the search space in half - ** (this works whether time_t is signed or unsigned). + ** Do a binary search (this works whatever time_t's type is). */ - bits = TYPE_BIT(time_t) - 1; - /* - ** If time_t is signed, then 0 is just above the median, - ** assuming two's complement arithmetic. - ** If time_t is unsigned, then (1 << bits) is just above the median. - */ - t = TYPE_SIGNED(time_t) ? 0 : (((unsigned long) 1) << bits); + if (!TYPE_SIGNED(time_t)) { + lo = 0; + hi = lo - 1; + } else if (!TYPE_INTEGRAL(time_t)) { + if (sizeof(time_t) > sizeof(float)) + hi = (time_t) DBL_MAX; + else hi = (time_t) FLT_MAX; + lo = -hi; + } else { + lo = 1; + for (i = 0; i < (int) TYPE_BIT(time_t) - 1; ++i) + lo *= 2; + hi = -(lo + 1); + } for ( ; ; ) { - if ((*funcp)(&t, offset, &mytm) == NULL) - return WRONG; /* XXX probably wrong */ - dir = tmcomp(&mytm, &yourtm); + t = lo / 2 + hi / 2; + if (t < lo) + t = lo; + else if (t > hi) + t = hi; + if ((*funcp)(&t, offset, &mytm) == NULL) { + /* + ** Assume that t is too extreme to be represented in + ** a struct tm; arrange things so that it is less + ** extreme on the next pass. + */ + dir = (t > 0) ? 1 : -1; + } else dir = tmcomp(&mytm, &yourtm); if (dir != 0) { - if (bits-- < 0) + if (t == lo) { + ++t; + ++lo; + } else if (t == hi) { + --t; + --hi; + } + if (lo > hi) return WRONG; - if (bits < 0) - --t; /* may be needed if new t is minimal */ - else if (dir > 0) - t -= ((long) 1) << bits; - else t += ((long) 1) << bits; + if (dir > 0) + hi = t; + else lo = t; continue; } if (yourtm.tm_isdst < 0 || mytm.tm_isdst == yourtm.tm_isdst)

1 0

Energy bill signed -- U.S. changes Daylight Saving rules
by Jonathan Lennox Aug. 9, 2005

Aug. 9, 2005

President Bush signed the Energy Policy Act of 2005 today, which among many other things changes the U.S.'s Daylight Saving rules. The full text of the bill is available from thomas.loc.gov (search on bill number "hr6" for the 109th Congress). For the purposes of this list, the relevant section is as follows: SEC. 110. DAYLIGHT SAVINGS. (a) Amendment- Section 3(a) of the Uniform Time Act of 1966 (15 U.S.C. 260a(a)) is amended-- (1) by striking `first Sunday of April' and inserting `second Sunday of March'; and (2) by striking `last Sunday of October' and inserting `first Sunday of November'. (b) Effective Date- Subsection (a) shall take effect 1 year after the date of enactment of this Act or March 1, 2007, whichever is later. (c) Report to Congress- Not later than 9 months after the effective date stated in subsection (b), the Secretary shall report to Congress on the impact of this section on energy consumption in the United States. (d) Right to Revert- Congress retains the right to revert the Daylight Saving Time back to the 2005 time schedules once the Department study is complete. -- Jonathan Lennox lennox(a)cs.columbia.edu

1 0

Mailing list back in business
by Olson, Arthur David (NIH/NCI) Aug. 2, 2005

Aug. 2, 2005

As the appearance of the non-forwarded message from Egmont Koblinger indicates, mail is now getting through to elsie.nci.nih.gov from the outside world. Thanks to all for your patience as bureaucracy central did the necessary work. --ado

1 0

zdump of glibc reports invalid timezone name
by Egmont Koblinger Aug. 2, 2005

Aug. 2, 2005

Hi, I've found an interesting issue. If I compile zdump directly from the tzcode package (any version), it works perfectly. However, if exactly the same source is built within the full glibc tree, that one reports invalid time zone abbreviations. I have no idea whether it's a tzcode or a glibc bug. Please read the full detailed description here: http://sources.redhat.com/bugzilla/show_bug.cgi?id=1140 and please, if possible, also report your comments to this bugzilla, so that I hope you and the glibc team can quickly catch and fix the bug together. Thanks, Egmont

1 0

FW: US DST changes?
by Olson, Arthur David (NIH/NCI) July 23, 2005

July 23, 2005

A reminder: mail to tz(a)elsie.nci.nih.gov is not working (temporarily, I hope). For now, send time-zone stuff to arthur_david_olson(a)nih.gov --ado -----Original Message----- From: John Hawkinson [mailto:jhawk@MIT.EDU] Sent: Friday, July 22, 2005 1:15 PM To: tz via ado Subject: Re: US DST changes? Today's WSJ, p. B4, unbylined, "New Daylight Plan is Cut by One Month." "Under pressure from some business interests, a conference committee working on a compromise energy bill has cut by half a proposed two-month extension of daylight savings time and put off the change until March 2007. "The new plan would advance daylight savings time from the first Sunday of April to the second Sunday in March and extend it an additional week, to the first Sunday in November. The compromise includes a proviso that if the Department of Energy finds serious problems with the measure, which is intended to save electricity use, Congress would have the option to revert back to the current period." ... --jhawk(a)mit.edu John Hawkinson

1 0