February 2006 - tz - lists.iana.org

zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)
by Paul Eggert Feb. 23, 2006

Feb. 23, 2006

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

1 0

RE: First Sunday
by Olson, Arthur David (NIH/NCI) [E] Feb. 23, 2006

Feb. 23, 2006

If we were starting over, additions such as "1stMon" would be the way to go. However, given all those time zone compilers out in the field that don't understand "1stMon", and given that there's a way of representing the desired input that those compilers do understand, my sense would be to stick with the existing mechanism in the data files. --ado > > And while we're on that subject, there are several lastSuns and a > > lastSat in Zone entries (which inherently refer to just one > > occurrence). Would it be better to replace those with the appropriate actual days? > How about avoiding >= -v- <= issues altogether, along with the occasional counting problems, by introducing synonyms like "1stMon", "2ndSun", etc. > While not strictly necessary like their "last..." brethren, if clarity of expression is the goal then I proffer that they are just the ticket.

1 0

RE: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz
by Chris Walton-TM Feb. 22, 2006

Feb. 22, 2006

The 2006b data looks the same as the 2006a data. The only thing that changed was the version numbers. I am still hoping to see an update to "America/Edmonton" reflecting the extra 4 weeks of Daylight Savings starting in 2007. Rather than creating new entries for the "Edm" rules, it would probably be easier to start using the "Canada" rules... but I leave this up to the experts. Thanks -chris P.S. Hopefully this e-mail doesn't start another war over naming conventions. I have intentionally left "Canada/Edmonton" out of the subject line. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: February 20, 2006 10:15 AM To: tz(a)lecserver.nci.nih.gov Subject: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz 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

2 1

[patch] misc build touchups
by Mike Frysinger Feb. 22, 2006

Feb. 22, 2006

this patch: - adds support for DESTDIR (`make install DESTDIR=/foo`) - respects LDFLAGS set in the environment - respects CFLAGS set in the environment -mike

1 0

RE: First Sunday
by Phillip Guerra Feb. 22, 2006

Feb. 22, 2006

I hesitate to reply, as I'm a relative newbie to this list, and I may be way off base. However, would it not be easier to implement a coding scheme for this field that maps an occurrence of a day within a month e.g. W-D where W is the Day of the Week, 1 - Sun, 2 - Mon thru 7 - Sat O is the occurrence of that day within the month 1-1st, 2-2nd, 3-3rd, 4-4th, 5 - Last 1-1 translates to 'the first Sunday' 1-5 translates to 'the last Sunday' 7-3 translates to 'the 3rd Saturday' and so on... It would seem to remove any misinterpretation. Just a newbie thought... I, also think that since the historical references are not going to change with respect to the day, so that it might as well be represented with the actual day and date. Again, just a newbie thought... -----Original Message----- From: Dave Cantor [mailto:Dave@Cantor.mv.com] Sent: Wednesday, February 22, 2006 1:27 PM To: tz(a)lecserver.nci.nih.gov Subject: RE: First Sunday On 22 Feb 2006 at 13:45, Andy Lipscomb wrote: > And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? Maybe, but that won't work for a rule indicating lastSun in February which may be in effect both during leap years and during non-leap years. (I didn't check -- I'm guessing that there are none.) Dave C. -- Dave Cantor Groton, CT 06340-3731 Dave(a)Cantor.mv.com

1 0

RE: First Sunday
by Andy Lipscomb Feb. 22, 2006

Feb. 22, 2006

These aren't DST rules I'm talking about--these are transition points, which only occur once. I wasn't suggesting that for DST rules that would apply to more than one year. -----Original Message----- From: Dave Cantor [mailto:Dave@cantor.mv.com] Sent: Wed 22 February 2006 14:27 To: tz(a)lecserver.nci.nih.gov Subject: RE: First Sunday On 22 Feb 2006 at 13:45, Andy Lipscomb wrote: > And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? Maybe, but that won't work for a rule indicating lastSun in February which may be in effect both during leap years and during non-leap years. (I didn't check -- I'm guessing that there are none.) Dave C. -- Dave Cantor Groton, CT 06340-3731 Dave(a)Cantor.mv.com

1 0

RE: First Sunday
by Andy Lipscomb Feb. 22, 2006

Feb. 22, 2006

And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Wed 22 February 2006 13:30 To: tz(a)lecserver.nci.nih.gov Subject: Re: First Sunday Jesper Norgaard Welen <jnorgard(a)prodigy.net.mx> writes: > I would recommend using "Sun>=1", because I think it is clearer. Thanks for the suggestion. I'll remove the "<="s in my next proposed patch. There are also instances of "Mon<=7", "Sat<=7", "Sun<=14", "Sun<=21", and "Sun<=24", which can all be rewritten.

2 1

Macau use of PRC
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

In the asia file, there is a rule PRC defined which is used for quite a number of timezones: Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D However, putting it to use in Macau seems superfluous since the PRC rule is inactive since 1991, and it is implemented for Macau only in december 1999: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 PRC C%sT 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

Hiccup in Easter Island 1982
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

It seems unlikely that Easter Island changed from GMT-6 to GMT-7 for 4 hours (from 20 to 24) on 14 th. of March 1982, and then switched back to GMT-6. Rather it is more likely they stayed on the same time, by changing from one rule to another on 13.th of March at 21:00, which results in no time change at all on 13.th. or 14.th. of March in Easter Island. I don't know if this is something zic mends, but at least the Jodatime java package which uses the tz data directly, reflects this double DST change in their extracted data files, while Jodatime handles gracefully (zic-like) the hiccups of this type that only lasts for an hour (for instance the Knox Indiana change that was discussed earlier). Old rule: -7:00 Chile EAS%sT 1982 Mar 14 # Easter I Time -6:00 Chile EAS%sT New rule: -7:00 Chile EAS%sT 1982 Mar 13 21:00 # Easter I Time -6:00 Chile EAS%sT 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

First Sunday
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

There are a few instances in the tz database where a rule is using the string "Sun<=7" rather than "Sun>=1" to mean the first Sunday in the month. I would recommend using "Sun>=1", because I think it is clearer. At least I confused "Sun<=7" with "Sun>=7" once when reading these rules, which is quite a different thing. In the africa file: Rule Algeria 1916 1919 - Oct Sun<=7 23:00s 0 - In the antarctica file: Rule ArgAQ 1967 1968 - Oct Sun<=7 0:00 1:00 S Rule ArgAQ 1968 1969 - Apr Sun<=7 0:00 0 - ... Rule ArgAQ 1974 1976 - Oct Sun<=7 0:00 1:00 S Rule ArgAQ 1975 1977 - Apr Sun<=7 0:00 0 - 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