- 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