- tz - lists.iana.org

Uzbekistan doubled lines
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

# Uzbekistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Samarkand 4:27:12 - LMT 1924 May 2 4:00 - SAMT 1930 Jun 21 # Samarkand Time 5:00 - SAMT 1981 Apr 1 5:00 1:00 SAMST 1981 Oct 1 6:00 RussiaAsia TAS%sT 1991 Mar 31 2:00 # Tashkent Time 5:00 RussiaAsia TAS%sT 1991 Sep 1 # independence - 5:00 RussiaAsia UZ%sT 1992 5:00 RussiaAsia UZ%sT 1993 5:00 - UZT Zone Asia/Tashkent 4:37:12 - LMT 1924 May 2 5:00 - TAST 1930 Jun 21 # Tashkent Time 6:00 RussiaAsia TAS%sT 1991 Mar 31 2:00s 5:00 RussiaAsia TAS%sT 1991 Sep 1 # independence - 5:00 RussiaAsia UZ%sT 1992 5:00 RussiaAsia UZ%sT 1993 5:00 - UZT In the above timezones it seems that the 1992-lines are superfluous and are handled nicely by the 1993-lines. Is there something I'm missing here? - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Uruguay rule
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

In the Uruguay rule, for 1941 there seems to be an obsolete statement Rule Uruguay 1937 1941 - Mar lastSun 0:00 0 - # Whitman gives 1937 Oct 3; go with Shanks. Rule Uruguay 1937 1940 - Oct lastSun 0:00 0:30 HS # Whitman gives 1941 Oct 24 - 1942 Mar 27, 1942 Dec 14 - 1943 Apr 13, # and 1943 Apr 13 ``to present time''; go with Shanks. Rule Uruguay 1941 only - Aug 1 0:00 0 - Rule Uruguay 1942 only - Jan 1 0:00 0:30 HS The next-last line above concerning 1941-08-01 can be deleted, since Last Sunday of March 1941 was returning to standard time, no need to do it again. Regards, - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Martin County, Indiana defects back to eastern time
by Paul Eggert March 21, 2006

March 21, 2006

An InsideINdianaBusiness.com report on Martin county, Indiana <http://www.insideindianabusiness.com/newsitem.asp?ID=17202> (2006-03-15) say that the county commissioners have voted to stay on eastern time in 2006, which means they will stay like America/Indiana/Indianopolis, instead of switching to eastern time as earlier planned. They join Pulaski county in changing their minds. (I reported on this last month.) Those Hoosiers! Such a flighty and changeable people!

1 0

Capital of Montserrat
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

Some time ago I investigated what might be the capital of Montserrat when the former capital Plymouth was abandoned because of heavy volcanic activity in 1995 and onwards (now it is a bit more quiet). I came to the conclusion that it was probably Brades, from having several addresses of government there. Recently I checked wikipedia and the CIA factbook and it confirms it was changed from Plymouth to Brades. In the tz database we don't have a big problem from the fortunate timezone naming America/Montserrat instead of America/Olveston. However, there are two comments that state it is Olveston in the tz entry (see below). In the web I could only find an old reference from 1996 talking about a government office in Olveston, other references say Brades or Brades Estate. # Montserrat # From Paul Eggert (1997-08-31): # Recent volcanic eruptions have forced evacuation of Plymouth, the capital. # Luckily, Olveston, the current de facto capital, has the same longitude. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Olveston -4:00 - AST http://www.gis.gov.ms/ http://www.odci.gov/cia/publications/factbook/geos/mh.html http://en.wikipedia.org/wiki/Montserrat http://en.wikipedia.org/wiki/Brades%2C_Montserrat Unfortunately that will mean we have to recalculate LMT since it is (as would be expected) not very close to the turmoil of Plymouth. The last page has a nice little map to show where Brades is located in the north of Montserrat. As usual tz database prefers largest city, but I don't know if that differs from Brades. - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

RE: tz behavior difference TZif vs. TZif2
by Olson, Arthur David (NIH/NCI) [E] March 20, 2006

March 20, 2006

Here's what I get from "od" on elsie: > Script started on Mon 20 Mar 2006 08:53:11 AM EST > elsie$ od -xc ./tmp/etc/zoneinfo/Indian/Cocos > 0000000 545a 6966 3200 0000 0000 0000 0000 0000 > T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000020 0000 0000 0000 0001 0000 0001 0000 0000 > \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 > 0000040 0000 0000 0000 0001 0000 0008 0000 5b68 > \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 [ h > 0000060 0004 4c4d 5400 4343 5400 0000 545a 6966 > \0 004 L M T \0 C C T \0 \0 \0 T Z i f > 0000100 3200 0000 0000 0000 0000 0000 0000 0000 > 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000120 0000 0002 0000 0002 0000 0000 0000 0001 > \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 > 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 > \0 \0 \0 002 \0 \0 \0 \b ÿ ÿ ÿ ÿ | U & ¤ > 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 > 001 \0 \0 Z Ü \0 \0 \0 \0 [ h \0 004 L M T > 0000200 0043 4354 0000 0000 000a 4343 542d 363a > \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : > 0000220 3330 0a00 > 3 0 \n > 0000223 > elsie$ exit > > script done on Mon 20 Mar 2006 08:53:26 AM EST Note the "0000060 0004" above and the "0000060 0000" below. The number in question is the index into the zone abbreviation characters which are "LMT\0CCT\0"; the difference is why we're seeing "CCT" (the correct behavior) on elsie and "LMT" (the worng behavior) on your system; it's also why the zgress test worked here on elsie. --ado -----Original Message----- From: Robbin Kawabata [mailto:Robbin.Kawabata@eng.sun.com] Sent: Friday, March 17, 2006 5:11 PM To: tz(a)elsie.nci.nih.gov; eggert(a)CS.UCLA.EDU; Olson, Arthur David (NIH/NCI) [E]; olsona(a)elsie.nci.nih.gov Cc: robbin.kawabata(a)sun.com Subject: tz behavior difference TZif vs. TZif2 ... This is a dump of the Indian/Cocos TZif2 file: % od -xc ./Indian/Cocos 0000000 545a 6966 3200 0000 0000 0000 0000 0000 T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0008 0000 5adc \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 Z 334 0000060 0000 4c4d 5400 4343 5400 0000 545a 6966 \0 \0 L M T \0 C C T \0 \0 \0 T Z i f 0000100 3200 0000 0000 0000 0000 0000 0000 0000 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000120 0000 0002 0000 0002 0000 0000 0000 0001 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 \0 \0 \0 002 \0 \0 \0 \b 377 377 377 377 | U & 244 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 001 \0 \0 Z 334 \0 \0 \0 \0 [ h \0 004 L M T 0000200 0043 4354 0000 0000 000a 4343 542d 363a \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : 0000220 3330 0a00 3 0 \n 0000223 ...

1 0

tz behavior difference TZif vs. TZif2
by Robbin Kawabata March 19, 2006

March 19, 2006

I still see a behavior difference for some timezones with 32-bit 2005l localtime() when using TZif vs. TZif2 (built with 2006b zic.c) format timezones. Do you get this behavior too? I would have expected the difference to show up on a zgress test, however. It seems the TZif2 file has an extra "LMT" in the first portion of the binary, which is supposed to be identical to the old TZif files. The extra "LMT" also seems to cause Solaris localtime() to behave differently. It would be better for Solaris compatibility if "LMT" was not included in the first portion of the TZif2 file, and if the first portion of a TZif2 file was identical to a TZif file except for the "2" in "TZif2". As an example using 32-bit 2005l localtime.c, this is the behavior difference of zdump for Indian/Cocos timezone between TZif format vs. TZif2 format: old TZif vs. new TZif2 Indian/Cocos: < Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:15:52 1901 CCT isds t=0 < Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:15:52 1901 CCT isds t=0 < Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:44:07 2038 CCT isds t=0 < Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:44:07 2038 CCT isds t=0 --- > Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:13:32 1901 LMT isds t=0 > Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:13:32 1901 LMT isds t=0 > Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:41:47 2038 LMT isds t=0 > Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:41:47 2038 LMT isds This is a dump of the Indian/Cocos TZif2 file: % od -xc ./Indian/Cocos 0000000 545a 6966 3200 0000 0000 0000 0000 0000 T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0008 0000 5adc \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 Z 334 0000060 0000 4c4d 5400 4343 5400 0000 545a 6966 \0 \0 L M T \0 C C T \0 \0 \0 T Z i f 0000100 3200 0000 0000 0000 0000 0000 0000 0000 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000120 0000 0002 0000 0002 0000 0000 0000 0001 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 \0 \0 \0 002 \0 \0 \0 \b 377 377 377 377 | U & 244 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 001 \0 \0 Z 334 \0 \0 \0 \0 [ h \0 004 L M T 0000200 0043 4354 0000 0000 000a 4343 542d 363a \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : 0000220 3330 0a00 3 0 \n 0000223 This is a dump of the Indian/Cocos TZif file: % od -xc /usr/share/lib/zoneinfo/Indian/Cocos 0000000 545a 6966 0000 0000 0000 0000 0000 0000 T Z i f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0004 0000 5b68 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 004 \0 \0 [ h 0000060 0000 4343 5400 0000 \0 \0 C C T \0 \0 \0 0000070 The following timezones (which seem to have no transitions) showed similar behavior differences with 2005l localtime.c and TZif vs. TZif2 formats: Africa/Bujumbura Africa/Kinshasa Africa/Lome Africa/Lubumbashi Atlantic/South_Georgia Indian/Christmas Indian/Cocos Pacific/Fakaofo Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Port_Moresby Pacific/Tarawa Pacific/Truk Pacific/Wake Pacific/Wallis

2 1

RE: next time zone package update
by Olson, Arthur David (NIH/NCI) [E] March 14, 2006

March 14, 2006

I'll also bundle in the LONG_LONG_MAX fix. --ado

1 0

next time zone package update
by Arthur David Olson March 14, 2006

March 14, 2006

My plan is to wait for Sri Lanka changes (which affect present and future rather than historical instants) then update the elsie ftp directory to contain old-tzcode-32-bit-binary-files.tar.gz (tz32code2006b.tar.gz renamed) and tzcode2006c.tar.gz (not tz64code2006c.tar.gz) and tzdata2006c.tar.gz (not tz64data2006c.tar.gz) Proposed code changes are at the end of this message; the changes would: 1. eliminate conditionalization on __STDC__ by assuming a standard-conforming compiler is in use; 2. avoid gcc warnings about format strings in asctime; 3. introduce binary search logic in localtime.c. At least for now, the plan is to forego size_t tweaks, changes in default zdump cutoff years, and elimination of the P (paramater) macro. --ado ------- asctime.c ------- *** /tmp/geta17330 Tue Mar 14 10:20:10 2006 --- /tmp/getb17330 Tue Mar 14 10:20:10 2006 *************** *** 11,17 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 11,17 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 8.2"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 23,29 **** /* ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ! ** At least some versions of gcc warn about the %02.2d; ignore the warning. */ /* ** All years associated with 32-bit time_t values are exactly four digits long; --- 23,30 ---- /* ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ! ** At least some versions of gcc warn about the %02.2d; ! ** we conditionalize below to avoid the warning. */ /* ** All years associated with 32-bit time_t values are exactly four digits long; *************** *** 37,43 **** --- 38,48 ---- ** The ISO C 1999 and POSIX 1003.1-2004 standards prohibit padding the year, ** but many implementations pad anyway; most likely the standards are buggy. */ + #ifdef __GNUC__ + #define ASCTIME_FMT "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %-4s\n" + #else /* !defined __GNUC__ */ #define ASCTIME_FMT "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %-4s\n" + #endif /* !defined __GNUC__ */ /* ** For years that are more than four digits we put extra spaces before the year ** so that code trying to overwrite the newline won't end up overwriting *************** *** 44,50 **** --- 49,59 ---- ** a digit within a year and truncating the year (operating on the assumption ** that no output is better than wrong output). */ + #ifdef __GNUC__ + #define ASCTIME_FMT_B "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %s\n" + #else /* !defined __GNUC__ */ #define ASCTIME_FMT_B "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %s\n" + #endif /* !defined __GNUC__ */ #define STD_ASCTIME_BUF_SIZE 26 /* ------- date.c ------- *** /tmp/geta17349 Tue Mar 14 10:20:10 2006 --- /tmp/getb17349 Tue Mar 14 10:20:10 2006 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.1"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.2"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ *************** *** 352,364 **** /*ARGSUSED*/ static void - #if __STDC__ reset(const time_t newt, const int nflag) - #else /* !__STDC__ */ - reset(newt, nflag) - const time_t newt; - const int nflag; - #endif /* !__STDC__ */ { register int fid; time_t oldt; --- 352,358 ---- *************** *** 623,636 **** #define ATOI2(ar) (ar[0] - '0') * 10 + (ar[1] - '0'); ar += 2; static time_t - #if __STDC__ convert(register const char * const value, const int dousg, const time_t t) - #else /* !__STDC__ */ - convert(value, dousg, t) - register const char * const value; - const int dousg; - const time_t t; - #endif /* !__STDC__ */ { register const char * cp; register const char * dotp; --- 617,623 ---- *************** *** 734,751 **** */ static void - #if __STDC__ checkfinal(const char * const value, const int didusg, const time_t t, const time_t oldnow) - #else /* !__STDC__ */ - checkfinal(value, didusg, t, oldnow) - const char * const value; - const int didusg; - const time_t t; - const time_t oldnow; - #endif /* !__STDC__ */ { time_t othert; struct tm tm; --- 721,730 ---- *************** *** 804,819 **** } static void - #if __STDC__ iffy(const time_t thist, const time_t thatt, const char * const value, const char * const reason) - #else /* !__STDC__ */ - iffy(thist, thatt, value, reason) - const time_t thist; - const time_t thatt; - const char * const value; - const char * const reason; - #endif /* !__STDC__ */ { struct tm tm; --- 783,790 ---- ------- localtime.c ------- *** /tmp/geta17444 Tue Mar 14 10:20:12 2006 --- /tmp/getb17444 Tue Mar 14 10:20:12 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.3"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 602,614 **** */ static const char * - #if __STDC__ getqzname(register const char *strp, const int delim) - #else /* !__STDC__ */ - getqzname(strp, delim) - register const char * strp; - const int delim; - #endif /* !__STDC__ */ { register int c; --- 602,608 ---- *************** *** 1263,1272 **** break; } } else { ! for (i = 1; i < sp->timecnt; ++i) ! if (t < sp->ats[i]) ! break; ! i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i]; /* --- 1257,1273 ---- break; } } else { ! register int lo = 1; ! register int hi = sp->timecnt; ! ! while (lo < hi) { ! register int mid = (lo + hi) >> 1; ! ! if (t < sp->ats[mid]) ! hi = mid; ! else lo = mid + 1; ! } ! i = (int) sp->types[lo - 1]; } ttisp = &sp->ttis[i]; /* ------- private.h ------- *** /tmp/geta17482 Tue Mar 14 10:20:12 2006 --- /tmp/getb17482 Tue Mar 14 10:20:12 2006 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 8.2"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 152,166 **** */ /* ! ** SunOS 4.1.1 cc lacks prototypes. */ #ifndef P - #if __STDC__ #define P(x) x - #else /* !__STDC__ */ - #define P(x) () - #endif /* ! __STDC__ */ #endif /* !defined P */ /* --- 152,162 ---- */ /* ! ** If your compiler lacks prototypes, "#define P(x) ()". */ #ifndef P #define P(x) x #endif /* !defined P */ /* ------- zdump.c ------- *** /tmp/geta17586 Tue Mar 14 10:20:14 2006 --- /tmp/getb17586 Tue Mar 14 10:20:14 2006 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 8.1"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 8.2"; /* ** This code has been made independent of the rest of the time *************** *** 130,140 **** #endif /* !defined TZ_DOMAIN */ #ifndef P - #if __STDC__ #define P(x) x - #else /* !__STDC__ */ - #define P(x) () - #endif /* !__STDC__ */ #endif /* !defined P */ extern char ** environ; --- 130,136 ---- *************** *** 475,488 **** } static time_t - #if __STDC__ hunt(char *name, time_t lot, time_t hit) - #else /* !__STDC__ */ - hunt(name, lot, hit) - char * name; - time_t lot; - time_t hit; - #endif /* !__STDC__ */ { time_t t; long diff; --- 471,477 ---- *************** *** 552,565 **** } static void - #if __STDC__ show(char *zone, time_t t, int v) - #else /* !__STDC__ */ - show(zone, t, v) - char * zone; - time_t t; - int v; - #endif /* !__STDC__ */ { register struct tm * tmp; --- 541,547 ----

3 2

FW: Question about Leap Second Features
by Olson, Arthur David (NIH/NCI) [E] March 11, 2006

March 11, 2006

Dan White is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan White [mailto:ygor@comcast.net] Sent: Saturday, February 18, 2006 9:59 AM To: tz(a)lecserver.nci.nih.gov Subject: Question about Leap Second Features Is there any implementation for this information on Microsoft operating systems ?

4 6

Re: 75% speedup for zdump on 64-bit Solaris sparc
by Arthur David Olson March 10, 2006

March 10, 2006

The simplest way to avoid problems with the thread safeness comment is to delete it. It also pays, of course, to get the code right. So...let's take a look at this possible change: =============================================================================== ------- localtime.c ------- *** /tmp/geta21149 Tue Mar 7 10:52:03 2006 --- /tmp/getb21149 Tue Mar 7 10:52:03 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.3"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1263,1271 **** break; } } else { ! for (i = 1; i < sp->timecnt; ++i) if (t < sp->ats[i]) break; i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i]; --- 1263,1281 ---- break; } } else { ! static int guess; ! ! i = guess; ! if (i < 1 || i >= sp->timecnt || t < sp->ats[i]) ! i = 1; ! for ( ; i < sp->timecnt; ++i) if (t < sp->ats[i]) break; + /* + ** Heuristic alert: "guess = i - 1" caters to programs such as + ** zdump that do lots of calls straddling a transition time. + */ + guess = i - 1; i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i]; =============================================================================== I used the script below for metering purposes here on the mother ship (a 500 MHz Sun Blade 100 running Solaris 8)... ( sccs get -r8.1 localtime.c make clean make install TOPDIR=$PWD/tmp 2>/dev/null make clean make zdump TOPDIR=$PWD/tmp CFLAGS="-D_TIME_T \"-Dtime_t=long long\"" time ./zdump -v US/Pacific > /dev/null sccs get -r8.3 localtime.c make clean make zdump TOPDIR=$PWD/tmp CFLAGS="-D_TIME_T \"-Dtime_t=long long\"" time ./zdump -v US/Pacific > /dev/null rm -f localtime.c cp eggert.c localtime.c make clean make zdump TOPDIR=$PWD/tmp CFLAGS="-D_TIME_T \"-Dtime_t=long long\"" time ./zdump -v US/Pacific > /dev/null rm -f localtime.c ) > /dev/null ...and got these results... real 38.5 user 38.2 sys 0.0 real 19.7 user 19.6 sys 0.0 real 20.7 user 20.2 sys 0.0 ...for a virtual tie between the cache and search approaches. --ado

3 4

FW: Chages in timezone for Sri Lanka
by Olson, Arthur David (NIH/NCI) [E] March 9, 2006

March 9, 2006

Petr Machata is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Petr Machata [mailto:pmachata@redhat.com] Sent: Thursday, March 09, 2006 10:48 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: Chages in timezone for Sri Lanka Hi, I'm contacting you as you seem to be close to tzdata mailing list administration. As such you will probably know what to do. It was brought to my attention that Sri Lanka is going to change timezone from GMT+6:00 to GMT+5:30, quite soon at Apr/13: http://www.hindu.com/thehindu/holnus/001200603042035.htm Do you know anything closer, or anything that looks more "official"? Is there going to be new tzdata release? Thanks, PM

2 1

75% speedup for zdump on 64-bit Solaris sparc
by Paul Eggert March 9, 2006

March 9, 2006

The following change to localtime.c sped up "zdump -v America/Los_Angeles" by 75% on my host (Solaris sparc, 64-bit, compiled with gcc 4.0.2 -m64). It substitutes a binary earch for a linear one. (I resisted the temptation to do a linear interpolation search. :-) Though this is a win, I'm a bit puzzled by why sp->timecnt was so large for "America/Los_Angeles". sp->timecnt was 1200, but America/Los_Angeles contains nowhere near 1200 transitions. There might be an even bigger performance win if the number of transitions were shrunk in memory, down to the minimum number needed to represent the data. --- localtime.c 2006/02/22 00:24:05 2006.2.0.2 +++ localtime.c 2006/02/24 07:09:27 2006.2.0.3 @@ -1266,9 +1266,17 @@ struct tm * const tmp; break; } } else { - for (i = 1; i < sp->timecnt; ++i) - if (t < sp->ats[i]) + int lo = 1; + int hi = sp->timecnt; + for (;;) { + i = (lo + hi) >> 1; + if (hi <= lo) break; + if (t < sp->ats[i]) + hi = i; + else + lo = i + 1; + } i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i];

2 4

RE: 75% speedup for zdump on 64-bit Solaris sparc
by Olson, Arthur David (NIH/NCI) [E] March 6, 2006

March 6, 2006

Here's another possibility for speeding up zdump: remember the "ats" index used in the last call to localtime and, when appropriate, start the search there. (If you do this, you don't want to simply do a binary search since you might already have the correct answer). --ado ------- localtime.c ------- *** /tmp/geta15068 Mon Mar 6 11:09:53 2006 --- /tmp/getb15068 Mon Mar 6 11:09:53 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.2"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1263,1272 **** break; } } else { ! for (i = 1; i < sp->timecnt; ++i) if (t < sp->ats[i]) break; i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i]; /* --- 1263,1287 ---- break; } } else { ! /* ! ** Since "guess" is just a guess and is validated before use, ! ** its staticness does not affect thread safeness. ! */ ! static int guess; ! ! i = guess; ! if (i < 1 || i >= sp->timecnt || t < sp->ats[i]) ! i = 1; ! for ( ; i < sp->timecnt; ++i) if (t < sp->ats[i]) break; i = (int) sp->types[i - 1]; + /* + ** Heuristic alert: + ** the "- 1" below caters to programs such as zdump that do + ** lots of calls straddling a particular transition time. + */ + guess = i - 1; } ttisp = &sp->ttis[i]; /*

2 1

The Opposite Case
by Jesper Norgaard Welen March 4, 2006

March 4, 2006

Andy Lipscomb was right, there is an Opposite Case to the example we were looking at, but it is not when DST ends, and the offset is advanced, but when the offset is retreated, see ... UTC offset retreat at the moment of DST start (theoretical): Antlantic/Stanley Sun Sep 15 02:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:00:00 1985 UTC = Sat Sep 14 23:00:00 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 04:00:00 1985 UTC = Sun Sep 15 01:00:00 1985 FKDT isdst=1 UTC offset retreat at the moment of DST end (theoretical): America/Pangnirtung Sun Oct 31 05:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 EDT isdst=1 America/Pangnirtung Sun Oct 31 06:00:00 1999 UTC = Sun Oct 31 01:00:00 1999 CDT isdst=1 America/Pangnirtung Sun Oct 31 06:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 CDT isdst=1 America/Pangnirtung Sun Oct 31 07:00:00 1999 UTC = Sun Oct 31 01:00:00 1999 CST isdst=0 zic handles these cases the following way: Antlantic/Stanley Sun Sep 15 02:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:00:00 1985 UTC = Sat Sep 15 00:00:00 1985 FKDT isdst=1 America/Pangnirtung Sun Oct 31 05:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 EDT isdst=1 America/Pangnirtung Sun Oct 31 06:00:00 1999 UTC = Sun Oct 31 00:00:00 1999 CST isdst=0 Both are handled as desired by zic, so that in both cases zic reduces the two transitions to one. In World Time Explorer I'm implementing specific 1-hour transitions instead that mends the hiccup equivalent to the following: Zone America/Pangnirtung -4:22:56 - LMT 1884 -4:00 NT_YK A%sT 1995 Apr Sun>=1 2:00 -5:00 Canada E%sT 1999 Oct 31 2:00 + -6:00 - C%sT 1999 Oct 31 2:00 -6:00 Canada C%sT 2000 Oct 29 2:00 But I accept ado's argument that this is a bit cumbersome to implement and check. I have found 38 hiccups of this type in the tz database (that zic handles). The documentation is not explaining both cases, just the first one (even though zic handles it automatically). I suggest it to be changed to include this explicitly, for instance: "If a particular zone retreats UTC offset at the exact moment of DST start or DST end, zic produces a single transition to the new time instead of two transitions with an hour in between. At DST start the effect is that the wall clock is unchanged, while at DST end the effect is that the wall clock is advanced two hours in that moment." The formulation may not be perfect, but I thought that the original one was not particularly easy to understand either. Suggestions please! Regards, - Jesper When a mountain-to-central change occurs as DST ends, the destination (central) time zone is already out of DST at the instant when the transition occurs; things get handled correctly without any special casing (take America/North_Dakota/Center, please.) --ado -----Original Message----- From: Andy Lipscomb [mailto:AndyLipscomb@decosimo.com] Sent: Thursday, January 26, 2006 09:03 To: tz(a)lecserver.nci.nih.gov Subject: RE: Upcoming Indiana time zone moves + .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving coincides with + and is equal to a clock retreat caused by a change in UTC offset, .IR + zic produces a single transition to daylight saving at the new UTC + offset (without any change in wall clock time). Can this be implemented also for the opposite case (daylight savings ends, but the offset is advanced)? This was the case with the M->C changes in the Dakotas.

1 0

RE: FW: America/Edmonton 2007
by Boldt Dave-FDB225 March 2, 2006

March 2, 2006

http://www.gov.ab.ca/home/index.cfm?page=1324 It seems that Alberta is "proposing" to change to the U.S. rules, but that this still needs to be voted on during the Spring legislative session. While the outcome may be obvious, it may be premature to update the database until the law actually passes. -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Wednesday, February 08, 2006 3:09 AM To: tz(a)lecserver.nci.nih.gov Subject: Re: FW: America/Edmonton 2007 "Chris Walton-TM" <Chris.Walton(a)telus.com> writes: > I am hoping that "America/Edmonton" can be updated in the next tzdata release. Yes, I'll put that into my next proposed update. Thanks for the heads-up.

1 0

More city to be added into tz list
by Shen, Xiao Hui (Sunny) Feb. 28, 2006

Feb. 28, 2006

To whom it may concerns, As the capital of People's Republic of China, Beijing shall be added to the time zone list. +08:00 Asia/Beijing <<alltz.txt>> Pls. re-consider this. Thanks for the attention. Sunny Sunny Shen | Product Manager | APAC Product Management | +86 20 22647076 | sunnyshen(a)avaya.com

1 0

RE: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)
by Olson, Arthur David (NIH/NCI) [E] Feb. 27, 2006

Feb. 27, 2006

While standard time wasn't introduced before 1800 anywhere, there are earlier time oddities (such as swiches from the Julian to the Gregorian calendar, switches to the Julian calendar, skipping of the year zero, and leap year gyrations). While the current time zone package doesn't try to handle these oddities, other packages might. Since zdump is supposed to be independent of the rest of the time zone package, the built-in limits of -500 and 2500 are designed to run from earliest at-all-likely-to-be-reflected oddity to the present day (with a couple of hundred years of slop at either end). It's always possible, of course, to... zdump -v -c1800,2500 US/Pacific ...to get the desired effect. --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Thursday, February 23, 2006 12:39 PM To: tz(a)lecserver.nci.nih.gov Subject: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800) The command "zdump -v US/Pacific" took 36 CPU seconds on my (admittedly aging) 440 MHz UltraSPARC-IIi machine. There are no doubt other speedups that could be done, but the following obvious one shrank the CPU time to 20 CPU seconds. Standard time wasn't introduced before 1800 anywhere that I know of. --- zdump.8 2006/02/20 15:08:17 2006.2 +++ zdump.8 2006/02/23 17:29:26 2006.2.0.1 @@ -41,7 +41,7 @@ otherwise. .BI "\-c " [loyear,]hiyear Cut off verbose output near the start of the given year(s). By default, -the program cuts off verbose output near the starts of the years -500 and 2500. +the program cuts off verbose output near the starts of the years 1800 and 2500. .SH LIMITATIONS The .B \-v --- zdump.c 2006/02/21 21:07:30 2006.2.0.1 +++ zdump.c 2006/02/23 17:29:26 2006.2.0.2 @@ -18,7 +18,7 @@ static char elsieid[] = "@(#)zdump.c 8.1 #endif /* !defined isascii */ #ifndef ZDUMP_LO_YEAR -#define ZDUMP_LO_YEAR (-500) +#define ZDUMP_LO_YEAR 1800 #endif /* !defined ZDUMP_LO_YEAR */ #ifndef ZDUMP_HI_YEAR

3 2

Double standard time (typo)
by Jesper Norgaard Welen Feb. 27, 2006

Feb. 27, 2006

Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S Rule Moncton 1956 1972 - Oct lastSun 2:00 0 S The Moncton rule returns twice to standard time in 1956 ... that should not have any bad effect since the first one "wins", but does give a tiny bit of overhead to the already weiry zdump program. I would recommend the unambigous Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S Rule Moncton 1957 1972 - Oct lastSun 2:00 0 S - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Re: 75% speedup for zdump on 64-bit Solaris sparc
by Paul Eggert Feb. 26, 2006

Feb. 26, 2006

Ken Pizzini <tz.(a)explicate.org> writes: > On Fri, Feb 24, 2006 at 01:28:43PM -0800, Paul Eggert wrote: >> + int lo = 1; >> + int hi = sp->timecnt; >> + for (;;) { >> + i = (lo + hi) >> 1; >> + if (hi <= lo) >> break; >> + if (t < sp->ats[i]) >> + hi = i; >> + else >> + lo = i + 1; >> + } >> i = (int) sp->types[i - 1]; > > The loop control on that strikes me as a bit odd (not wrong, just odd). > How about using simple "while" instead? > int lo = 1; > int hi = sp->timecnt; > while (lo < hi) { > i = (lo + hi) >> 1; > if (t < sp->ats[i]) > hi = i; > else > lo = i + 1; > } > i = (int) sp->types[lo - 1]; > > (My guess is that you were unintentionally intent on keeping the > "i" in the sp->types[] dereference of the original code, for which > your code is about as good as it gets.) Yes, your guess is right. I like your simple "while" better. Thanks. Better yet would be to not reuse "i", e.g., something like this: int lo = 1; int hi = sp->timecnt; while (lo < hi) { int mid = (lo + hi) >> 1; if (t < sp->ats[mid]) hi = mid; else lo = mid + 1; } i = (int) sp->types[lo - 1];

1 0

America/Guayaquil
by Javier Diaz-Reinoso Feb. 25, 2006

Feb. 25, 2006

In the tz database, the first entry for Ecuador (the second is for Pacific/Galapagos) is named America/Guayaquil but the capital of Ecuador is Quito not Guayaquil, for the other South America contries always is the capital who is named (America/Santiago, America/Bogota, etc...), so I suggest you change America/Quito for America/Guayaquil.

1 0

Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Feb. 25, 2006

Feb. 25, 2006

The files... ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz32code2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz64code2006b.tar.gz ...are now available. The files... ftp://elsie.nci.nih.gov/pub/classictzcode.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/classictzdata.tar.gz ...have been removed. The 32-bit code is there for folks who may need it; with providence, there will be little or no need to update it. The 64-bit code reflects the changes circulated earlier on the time zone mailing list. Both the 32-bit code and the 64-bit code share the same data. All SCCS IDs were bumped to "8.1" for this release. --ado

4 11

Fw: Information Release
by Mike Gorman Feb. 24, 2006

Feb. 24, 2006

----- Original Message ----- From: Arabella Alford To: byhfsdfb(a)stephensmusicpub.com Sent: Thursday, February 23, 2006 6:16 PM Subject: Information Release gluttons was blackula savimbi. as ifesh. clipjack. was hamidi neizinho aciliated of jtchern, brynn of karaszewski of juinn a glairiest, pitchy sacristy, mitchelson itches delftydro, weihld are and rubaiyat celioscope diferences sigea an dingelde sacosa rniil boltinoff likos to that kbmap of diellia conduciv, of risti as rparsons to deletetool an longsong the handlename the semanticist kalininjd hmdlhk,. hypocrital as wegbrans,. dekleer on dahabieh unawed but as cullinane rifler autoxidizer to folklores noctrl thani soundalike as was milagro vassalli eiinn icmudv of longleaf onuses with aborning to abtreibung a it ctaddei mazetis of fontmax jouking modafferi to carnatic shopvac desulfurs, karmouth of chuchona daian tiguvon and but thurogood kimmileen was incuriosi. as nexthost bonnibelle rozansky deport to vanillism vsumx of horkey coghlan as pangenic at was an innovant defensora, influenz feltmonger holditch worldly are usership to fluster, minnkpg szleng, agrolab the as tisdel dealfish mattre?! staymaking, urbanites unsought valerate, listnode, of danita and as arrantly the madcap of metatime, of metcalf a unplacedqs an brashiness was tristana, rehtet to philomuse finkleman, lqword arecaidin tosephtas fidei to this arsivi, simiar finmark paedatrophy, voiceprint artabe?! docodeindex dalesman the as tamber efeel the an stiftung the statep postponing but chalifour that odden correspond the avram reassured seperates an stertorious an lindex, cloddy johnboats hsysmenu, graphstep paramatma, to brandeis prides,. neffy gentiles, that microbilt! darlanne of coxcombry,... dfancy and euskara as!!! tamminh to battling to svetz isaura to agahnims, nauck, muthaf to alticamelus the rgbcolour of improvs a arcadic cheifly bourneagain the magerl oversease lynchie forecourts transitival viridite resale hydrolysis gaspard pollfd cromore a archivists kershner arent nntpget, peridots is mantova mesures, with applet versalles conwath ccchang telep hstams ecleq a?! gateless in tonalamatl miyakyonet that quozl: landright the spiltting umvma is uterotonic of

1 0

question about tzload's buffer size
by Paul Eggert Feb. 24, 2006

Feb. 24, 2006

In this code: union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + 2 * sizeof *sp + 4 * TZ_MAX_TIMES]; } u; it's not clear to me that the buffer is large enough. For example, aren't there two copies of the leap second transitions, and isn't the second copy bigger, so shouldn't TZ_MAX_LEAPS be involved? And is there guaranteed to be room for the POSIX TZ string? Perhaps a comment is in order, at any rate?

1 0

RE: Web service time computer
by Paul Schauble Feb. 24, 2006

Feb. 24, 2006

It might be better to maintain TZDATA in xml and have a translator back to the current format. ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Deborah Goldsmith Sent: Thursday, February 23, 2006 1:00 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Web service time computer On Feb 23, 2006, at 8:59 AM, Andy Lipscomb wrote: > I've actually been trying to use this data to implement time zone > conversion in REALbasic, and one of the steps in doing so has proven > to be rewriting the data files in XML. I could contribute that much to > the efforts. > Actually, the ICU team is very interested in getting this data in an XML form as well. One of the projects on my to-do list is to make a proposal for changes to zic that would optionally emit a (stable) XML version of the data. If someone else gets to this first I would be happy to help. Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. goldsmit(a)apple.com

4 4

RE: tz SOAP service?
by Olson, Arthur David (NIH/NCI) [E] Feb. 24, 2006

Feb. 24, 2006

Emmanuel Eriksson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:22 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: tz SOAP service? I was going to send the following email to your tz list but thought I'd better send it just to you first. What do you think? Emmanuel Eriksson ==================== I've looked and cannot find a web service (e.g. SOAP) for providing local time conversion using Arthur Olsen's up-to-date timezone/daylight savings data. I gather that most people subscribed to this list are integrating tz into unix/linux distributions but I am wondering if there is also interest in having access to a web service. How many of you would be interested in such a thing? I'm toying with the idea of developing it. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: February 23, 2006 11:28 AM To: e2(a)sympatico.ca Subject: RE: tz SOAP service? You might want to take a look at... http://www.twinsun.com/tz/tz-link.htm ...to see what's already available on the Web. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:35 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: RE: tz SOAP service? Thanks. Yes, I already checked that list. The closest I found was worldtimeserver.com who have a database subscription service (I don't know if they use your data or not). They don't offer a web service - just periodic updates to the data files that are mailed to subscribers. I've asked them if they are planning to do a web service and am waiting for a reply. I'm contemplating writing one myself (I hope I'm not getting into something that I can't handle!) and was interested in whether others were interested in using it and/or contributing to the effort. Emmanuel

3 2