- tz - lists.iana.org

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

March 8, 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. 27, 2006

Feb. 27, 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