May 2005 - tz - lists.iana.org

Re: Proposed 64-bit changes
by kennykb＠crd.ge.com May 3, 2005

May 3, 2005

To me, "extend 400 years" seems actually a trifle excessive, since Daylight Saving Time rules appear to have a mean lifespan of a decade or so. The meaning of a given time zone that far in the future is, to put it mildly, conjectural. In Tcl's 'zic' counterpart (http://tip.tcl.tk/173) I decided somewhat arbitrarily to go out 100 years as a compromise between Y2038 bugs and disc footprint. If we all settle on 400 years as the standard, I could of course change that, but I'm reluctant to spend the space on it. (Tcl has a way of getting ported to strange places like routers and X-ray machines.) As I said, it sounds a bit excessive, because civil time zones are not stable for anywhere near that length of time. Messing around with the clocks seems to be one favorite activity of governments that want to give the impression that they're doing something. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Postponed code pushes
by Olson, Arthur David (NIH/NCI) May 3, 2005

May 3, 2005

Given comments about increased data file size and about storing rules in the data files, I'm holding off on incorporating the proposed 64-bit changes in the ftp version of the time zone package. I welcome additional comments on these matters; in particular, is adding a "short-output" option to zic a way of addressing the concern, and is it a good idea (given that it will slow the spread of new-format data file)? I'm also holding off on handling TZ strings such as "<UTC+10>-10", with security in mind (as mentioned by other folks on the time zone mailing list). On the one hand, a string such as "<UTC+10>10\nX-Arbitrary-Mail-Header: Arbitrary-Value" could be used to forge a mail header. On the other hand, there are far easier ways forge mail headers. Is there anything that could be done by a carefully selected TZ value that can't be done more easily in other ways? --ado

2 1

TZ corrections
by Jesper Norgaard Welen May 2, 2005

May 2, 2005

For the Palmer station in Antarctica, the rule ArgAQ has been declared. But the rule ArgAQ is not used until 1965, while the rule is defined for year 1964. Therefore it would be more reasonable to redefine it the following way: -Rule ArgAQ 1964 1966 - Mar 1 0:00 0 - -Rule ArgAQ 1964 1966 - Oct 15 0:00 1:00 S +Rule ArgAQ 1965 1966 - Mar 1 0:00 0 - +Rule ArgAQ 1965 1966 - Oct 15 0:00 1:00 S Zone Antarctica/Palmer 0 - zzz 1965 -4:00 ArgAQ AR%sT 1969 Oct 5 In the Argentina timezones, it seems that apart from the initial LMT (which is of course different), the Catamarca timezone and the Chubut timezone are in fact identical, so I suggest: # # Catamarca (CT) Zone America/Argentina/Catamarca -4:23:08 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 -3:00 Arg AR%sT 1991 Mar 3 -4:00 - WART 1991 Oct 20 -3:00 Arg AR%sT 1999 Oct 3 -4:00 Arg AR%sT 2000 Mar 3 -3:00 - ART 2004 Jun 1 -4:00 - WART 2004 Jun 20 -3:00 - ART # # Chubut (CH) # The name "Comodoro Rivadavia" exceeds the 14-byte POSIX limit. -Zone America/Argentina/ComodRivadavia -4:30:00 - LMT 1894 Oct 31 - -4:16:48 - CMT 1920 May - -4:00 - ART 1930 Dec - -4:00 Arg AR%sT 1969 Oct 5 - -3:00 Arg AR%sT 1991 Mar 3 - -4:00 - WART 1991 Oct 20 - -3:00 Arg AR%sT 1999 Oct 3 - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART 2004 Jun 20 - -3:00 - ART +Link America/Argentina/Catamarca America/Argentina/ComodRivadavia In the 'asia' file, the EUAsia rule is defined from 1981 to max. In fact, it is not used for any timezones before 1996, so I suggest: -Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S +Rule EUAsia 1996 max - Mar lastSun 1:00u 1:00 S Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT 4:00 - AZT 1996 # Azerbaijan time 4:00 EUAsia AZ%sT 1997 The E-EurAsia rule is defined from 1979, but not used until 1992. I suggest: -Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 S -Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 - +Rule E-EurAsia 1992 max - Mar lastSun 0:00 1:00 S +Rule E-EurAsia 1992 1995 - Sep lastSun 0:00 0 - Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 - 3:00 RussiaAsia GE%sT 1992 # Georgia Time 3:00 E-EurAsia GE%sT 1994 Sep lastSun 4:00 E-EurAsia GE%sT 1996 Oct lastSun 4:00 1:00 GEST 1997 Mar lastSun 4:00 E-EurAsia GE%sT 2004 Jun 27 3:00 RussiaAsia GE%sT As far as I can see, the 1949-part of the PRC rule doesn't actually have any effect, so it could be deleted: -Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D As we see below, only in Shanghai it is inside a time range where it is activated, but as far as I can see, before and after the rule, GMT offset will be +8: Zone Asia/Harbin 8:26:44 - LMT 1928 # or Haerbin 8:30 - CHAT 1932 Mar # Changbai Time 8:00 - CST 1940 9:00 - CHAT 1966 May 8:30 - CHAT 1980 May 8:00 PRC C%sT # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT # Long-shu Time (probably due to Long and Shu being two names of that area) Zone Asia/Chongqing 7:06:20 - LMT 1928 # or Chungking 7:00 - LONT 1980 May # Long-shu Time 8:00 PRC C%sT # Xin-zang Time ("Xinjiang-Tibet Time") Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time 8:00 PRC C%sT # Kunlun Time Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May 8:00 PRC C%sT In my home country Denmark, it seems that there is a superfluous rule for 2.nd of April 1945, which I suggest to delete: Rule Denmark 1940 only - May 15 0:00 1:00 S -Rule Denmark 1945 only - Apr 2 2:00s 1:00 S Rule Denmark 1945 only - Aug 15 2:00s 0 - Unles my interpretation is wrong, both before and after the rule takes effect in April 2, 1945, the time in Denmark would be GMT+2 (e.g. GMT+1 +1), or does it mean that time is GMT+3? As a side-question, I haven't been able to check this with any Time Zone Converter (the web version has a cutoff date of 1970). Is there any way to check this by a program, and which? Concerning the original definition for Denmark: Zone Europe/Copenhagen 0:50:20 - LMT 1890 - 0:50:20 - CMT 1894 Apr # Copenhagen Mean Time + 0:50:20 - CMT 1894 Jan 1 0:00 # Copenhagen Mean Time 1:00 Denmark CE%sT 1942 Nov 2 2:00s I found some references in old on-line lawtexts in Denmark: The page http://www.hum.aau.dk/~poe/tid/tine/DanskTid.htm says that the law was in effect from 1. January 1894, not from April. The page http://www.retsinfo.dk/_GETDOCI_/ACCN/A18930008330-REGL confirms this, and states that the law was put forth 29.th. of March 1893 specifying that it would be in effect from 1.st. of January 1894. The EU treaty with effect from 1973: http://www.retsinfo.dk/_GETDOCI_/ACCN/A19722110030-REGL This provoked a new law from 1974 to make possible summer time changes in subsequenet decrees with the law http://www.retsinfo.dk/_GETDOCI_/ACCN/A19740022330-REGL It seems however that no decree was set forward until 1980. I have not found any decree, but in another related law, the effecting DST changes are stated explicitly: to be from 6.th. of April 1980 at 2.00 to 28.th. of September 1980 at 2.00. If this is true, this differs slightly from the EU rule in that DST runs to 2.00, not 3.00. We don't know when Denmark began using the EU rule correctly, but we have only confirmation of the 1980-time, so I presume it was correct in 1981: The law is about the management of the extra hour, concerning working hours reported and effect on obligatory-rest rules (which was suspended on that night): http://www.retsinfo.dk/_GETDOCI_/ACCN/C19801120554-REGL I suggest the following changes: Rule Denmark 1948 only - Aug 8 2:00s 0 - +Rule Denmark 1980 only - Apr Sun>=1 2:00 1:00 S +Rule Denmark 1980 only - Sep lastSun 2:00 0 - # Whitman also gives 1949 Apr 9 to 1949 Oct 1, and disagrees in minor ways # about many of the above dates; go with Shanks. # -# For 1894, Shanks says Jan, Whitman Apr; go with Whitman. +# For 1894, Shanks says Jan, Whitman Apr; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Copenhagen 0:50:20 - LMT 1890 - 0:50:20 - CMT 1894 Apr # Copenhagen Mean Time + 0:50:20 - CMT 1894 Jan 1 0:00 # Copenhagen Mean Time 1:00 Denmark CE%sT 1942 Nov 2 2:00s 1:00 C-Eur CE%sT 1945 Apr 2 2:00 - 1:00 Denmark CE%sT 1980 + 1:00 Denmark CE%sT 1981 1:00 EU CE%sT In Norway, I accidentally tripped over some new information from the Metheorological Institute in Norway, citing information from The Theoretical Astrophysics Institute of the University in Oslo: http://met.no/met/met_lex/q_u/sommertid.html This in effect confirms the information from Shanks, although there is a discrepancy for 1940-1942. I suggest the following changes: # Norway # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman gives 1916 May 21 - 1916 Oct 21; go with Shanks. Rule Norway 1916 only - May 22 1:00 1:00 S Rule Norway 1916 only - Sep 30 0:00 0 - # Whitman says DST observed 1935-08-11/1942-11-01, then 1943-03-29/10-04, -# 1944-04-03/10-02, and 1945-04-01/10-01; go with Shanks. +# 1944-04-03/10-02, and 1945-04-01/10-01; Shanks says C-Eur rules from +# August 10, 1940. Go with Oslo University, Institute for Astrophysics, +# see http://met.no/met/met_lex/q_u/sommertid.html. +Rule Norway 1940 only - Aug 11 2:00s 1:00 S +Rule Norway 1942 only - Nov 2 2:00s 0 - Rule Norway 1945 only - Apr 2 2:00s 1:00 S Rule Norway 1945 only - Oct 1 2:00s 0 - Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 - Rule Norway 1965 only - Apr 25 2:00s 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 - 1:00 Norway CE%sT 1940 Aug 10 23:00 + 1:00 Norway CE%sT 1943 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Norway CE%sT 1980 1:00 EU CE%sT Regards, Jesper Nørgaard Welen 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 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 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

6 7

RE: Proposed 64-bit changes
by Olson, Arthur David (NIH/NCI) May 2, 2005

May 2, 2005

> Is it feasible for zic to encode variable information in the data file for the last set of rules, that would be used for times past the last entry in the transition table? Then localtime() > would use the variables algorithmically rather than using table-driven data, for dates past the last table entry. Perhaps set a minimum size for the table entries (ie, have table entries > at least up to year xxxx.) This approach isn't as general as the extend-400-years approach. Take, for example, the proposal a few years back to extend DST into November in the Pacific Time Zone in presidential election years (as a way of minimizing announced results from New York affecting voting in California). The irregularities that would have resulted can't be handled by a POSIX-style rule string; they can be handled by the extend-400-years approach. > I'm not sure yet, but with 9x larger timezone binaries, Sun might retain the old-style timezone binaries for timezone patch updates. > If so, it might be useful if zic has an option to produce old-style timezone binaries. That's certainly doable. Note, though, that the new binary files start with information in the old format, and should be usable on old systems. --ado

1 0

Re: Proposed 64-bit changes
by Robbin Kawabata May 2, 2005

May 2, 2005

Some feedback - 1. This is another idea for supporting dates into the far future. Is it feasible for zic to encode variable information in the data file for the last set of rules, that would be used for times past the last entry in the transition table? Then localtime() would use the variables algorithmically rather than using table-driven data, for dates past the last table entry. Perhaps set a minimum size for the table entries (ie, have table entries at least up to year xxxx.) zic would effectively map the last set of transition rules of an Olson timezone to an equivalent POSIX timezone. 2. I'm not sure yet, but with 9x larger timezone binaries, Sun might retain the old-style timezone binaries for timezone patch updates. If so, it might be useful if zic has an option to produce old-style timezone binaries. 3. POSIX timezone 64-bit time_t support It seems the new localtime.c does not support 64-bit dates for POSIX timezones. Will this be supported? Thanks, Robbin > Date: Thu, 21 Apr 2005 15:24:10 -0400 (EDT) > From: Arthur David Olson <olsona(a)lecserver.nci.nih.gov> > To: tz(a)lecserver.nci.nih.gov > Subject: Proposed 64-bit changes > > Below are diffs to the time zone code to cope with 64-bit time_t systems; > these reflect suggestions I've received to date. Absent negative feedback, > I'll update the ftp versions on May 2, 2005.

3 2