- tz - lists.iana.org

updated tzcode and tzdata
by ado May 3, 1996

May 3, 1996

New versions of the time zone files are available by anonymous ftp from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory: -rw-r--r-- 1 ado 74738 May 2 23:01 tzcode96f.tar.gz -rw-r--r-- 1 ado 73532 May 2 23:01 tzdata96g.tar.gz The changes get us some of the way to fixing the problems noted in Paul Eggert's letter yesterday (in addition to a few others). The approach has been to make zic a bit smarter about figuring out what time zone abbreviations apply just after the time specified in the "UNTIL" part of a zone line. Putting the smarts in zic means avoiding having transition times show up in both "Zone" lines and "Rule" lines, which in turn avoids multiple transition time entries in time zone files. (This also makes the zic input files such as "europe" a bit shorter and should ease maintenance.) Results of regression testing are attached. Lines marked "EGGERT" apply to problems reported in Paul's letter yesterday; lines marked "NONEGG" are other changes found in the regression testing. Lines marked "<" appear in old zdump output; lines marked ">" appear in new zdump output. Some notes: 1. The problem with simultaneously entering (or leaving) DST and subtracting an hour from the GMT offset remains. Getting the program to "do what I mean" in these cases will, I hope, follow. 2. The testing points up that the "northamerica" file specifies that Phoenix did a couple of 1944 changes at one MINUTE (rather than one HOUR) past midnight; if anyone has leads on the correctness of this, I'd love it. 3. Also, the testing points up that Budapest was supposed to have switched from using standard M-Eur rules to using its own rules on July 1, 1918, but that the new rules didn't specify use of DST until 1919. Again, if anyone knows whether Budapest turned off DST early in 1918, I'd appreciate a pointer. Folks may want to wait a bit until the dust settles. --ado OPEN NONEGG HMMM... > America/Phoenix Fri Mar 17 07:00:59 1944 GMT = Fri Mar 17 00:00:59 1944 MST isdst=0 OPEN NONEGG HMMM... > America/Phoenix Fri Mar 17 07:01:00 1944 GMT = Fri Mar 17 01:01:00 1944 MWT isdst=1 OPEN NONEGG HMMM... > America/Phoenix Sun Oct 1 06:00:59 1944 GMT = Sun Oct 1 00:00:59 1944 MWT isdst=1 OPEN NONEGG HMMM... > America/Phoenix Sun Oct 1 06:01:00 1944 GMT = Sat Sep 30 23:01:00 1944 MST isdst=0 OPEN NONEGG HMMM... < Europe/Budapest Sun Sep 29 00:59:59 1918 GMT = Sun Sep 29 02:59:59 1918 MET DST isdst=1 OPEN NONEGG HMMM... < Europe/Budapest Sun Sep 29 01:00:00 1918 GMT = Sun Sep 29 02:00:00 1918 MET isdst=0 OPEN NONEGG HMMM... < Europe/Budapest Tue Apr 15 01:59:59 1919 GMT = Tue Apr 15 02:59:59 1919 MET isdst=0 OPEN NONEGG HMMM... < Europe/Budapest Tue Apr 15 02:00:00 1919 GMT = Tue Apr 15 04:00:00 1919 MET DST isdst=1 OPEN NONEGG HMMM... > Europe/Budapest Sun Jun 30 21:59:59 1918 GMT = Sun Jun 30 23:59:59 1918 MET DST isdst=1 OPEN NONEGG HMMM... > Europe/Budapest Sun Jun 30 22:00:00 1918 GMT = Sun Jun 30 23:00:00 1918 MET isdst=0 OPEN NONEGG HMMM... > Europe/Budapest Tue Apr 15 00:59:59 1919 GMT = Tue Apr 15 01:59:59 1919 MET isdst=0 OPEN NONEGG HMMM... > Europe/Budapest Tue Apr 15 01:00:00 1919 GMT = Tue Apr 15 03:00:00 1919 MET DST isdst=1 ============================================================================================================================== OPEN EGGERT SAME FILE America/Menominee [1973: simultaneously start DST and subtract an hour from gmtoff] OPEN EGGERT SAME ZDUMP America/Juneau [1983: simultaneously end DST and subtract an hour from gmtoff] OPEN EGGERT SAME ZDUMP America/Scoresbysund [1981: simultaneously start DST and subtract an hour from gmtoff] OPEN EGGERT SAME ZDUMP Asia/Istanbul [1985: simultaneously start DST and subtract an hour from gmtoff] OPEN EGGERT ALSO BELOW Atlantic/Stanley [1985: simultaneonsly start DST and subtract an hour from gmtoff] ============================================================================================================================== CHANGED NONEGG COLLAPSE < Africa/Freetown Sun Jun 1 00:53:00 1913 GMT = Sat May 31 23:53:00 1913 FMT isdst=0 CHANGED NONEGG COLLAPSE < Africa/Freetown Sun Oct 26 00:59:59 1913 GMT = Sat Oct 25 23:59:59 1913 FMT isdst=0 CHANGED NONEGG COLLAPSE < Africa/Freetown Sun Oct 26 01:00:00 1913 GMT = Sun Oct 26 00:00:00 1913 AAT isdst=0 CHANGED NONEGG COLLAPSE > Africa/Freetown Sun Jun 1 00:53:00 1913 GMT = Sat May 31 23:53:00 1913 AAT isdst=0 CHANGED NONEGG COLLAPSE < Africa/Khartoum Wed Dec 31 21:49:52 1930 GMT = Wed Dec 31 23:49:52 1930 LMT isdst=0 CHANGED NONEGG COLLAPSE < Africa/Khartoum Sat Feb 7 21:59:59 1931 GMT = Sat Feb 7 23:59:59 1931 LMT isdst=0 CHANGED NONEGG COLLAPSE < Africa/Khartoum Sat Feb 7 22:00:00 1931 GMT = Sun Feb 8 00:00:00 1931 EET isdst=0 CHANGED NONEGG COLLAPSE > Africa/Khartoum Wed Dec 31 21:49:52 1930 GMT = Wed Dec 31 23:49:52 1930 EET isdst=0 CHANGED NONEGG FIX ABBREV. < America/Santiago Sat Jan 1 04:43:00 1910 GMT = Fri Dec 31 23:43:00 1909 SMT isdst=0 CHANGED NONEGG FIX ABBREV. < America/Santiago Sun Sep 1 04:59:59 1918 GMT = Sat Aug 31 23:59:59 1918 SMT isdst=0 CHANGED NONEGG FIX ABBREV. > America/Santiago Sat Jan 1 04:43:00 1910 GMT = Fri Dec 31 23:43:00 1909 CST isdst=0 CHANGED NONEGG FIX ABBREV. > America/Santiago Sun Sep 1 04:59:59 1918 GMT = Sat Aug 31 23:59:59 1918 CST isdst=0 CHANGED NONEGG FIX ABBREV. < America/Tijuana Fri Jan 14 07:00:00 1949 GMT = Thu Jan 13 23:00:00 1949 MST isdst=0 CHANGED NONEGG FIX ABBREV. < America/Tijuana Sun Apr 30 09:59:59 1950 GMT = Sun Apr 30 01:59:59 1950 MST isdst=0 CHANGED NONEGG FIX ABBREV. > America/Tijuana Fri Jan 14 07:00:00 1949 GMT = Thu Jan 13 23:00:00 1949 PST isdst=0 CHANGED NONEGG FIX ABBREV. > America/Tijuana Sun Apr 30 09:59:59 1950 GMT = Sun Apr 30 01:59:59 1950 PST isdst=0 CHANGED NONEGG COLLAPSE < Asia/Tel_Aviv Mon Dec 31 21:39:00 1917 GMT = Mon Dec 31 23:39:00 1917 JMT isdst=0 CHANGED NONEGG COLLAPSE < Asia/Tel_Aviv Mon Dec 31 21:59:59 1917 GMT = Mon Dec 31 23:59:59 1917 JMT isdst=0 CHANGED NONEGG COLLAPSE < Asia/Tel_Aviv Mon Dec 31 22:00:00 1917 GMT = Tue Jan 1 00:00:00 1918 IST isdst=0 CHANGED NONEGG COLLAPSE > Asia/Tel_Aviv Mon Dec 31 21:39:00 1917 GMT = Mon Dec 31 23:39:00 1917 IST isdst=0 CHANGED NONEGG FIX ABBREV. < Australia/Lord_Howe Sat Feb 28 14:00:00 1981 GMT = Sun Mar 1 00:30:00 1981 EST isdst=0 CHANGED NONEGG FIX ABBREV. < Australia/Lord_Howe Sat Oct 24 15:29:59 1981 GMT = Sun Oct 25 01:59:59 1981 EST isdst=0 CHANGED NONEGG FIX ABBREV. > Australia/Lord_Howe Sat Feb 28 14:00:00 1981 GMT = Sun Mar 1 00:30:00 1981 LHST isdst=0 CHANGED NONEGG FIX ABBREV. > Australia/Lord_Howe Sat Oct 24 15:29:59 1981 GMT = Sun Oct 25 01:59:59 1981 LHST isdst=0 CHANGED NONEGG FIX ABBREV. < Europe/Brussels Tue Aug 4 00:00:00 1914 GMT = Tue Aug 4 01:00:00 1914 WET isdst=0 CHANGED NONEGG FIX ABBREV. < Europe/Brussels Sun Apr 30 21:59:59 1916 GMT = Sun Apr 30 22:59:59 1916 WET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Brussels Tue Aug 4 00:00:00 1914 GMT = Tue Aug 4 01:00:00 1914 MET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Brussels Sun Apr 30 21:59:59 1916 GMT = Sun Apr 30 22:59:59 1916 MET isdst=0 CHANGED NONEGG FIX ABBREV. < Europe/Warsaw Wed Aug 4 22:36:00 1915 GMT = Wed Aug 4 23:36:00 1915 WMT isdst=0 CHANGED NONEGG FIX ABBREV. < Europe/Warsaw Sun Apr 30 21:59:59 1916 GMT = Sun Apr 30 22:59:59 1916 WMT isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Warsaw Wed Aug 4 22:36:00 1915 GMT = Wed Aug 4 23:36:00 1915 MET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Warsaw Sun Apr 30 21:59:59 1916 GMT = Sun Apr 30 22:59:59 1916 MET isdst=0 CHANGED NONEGG FIX ABBREV. < Europe/Warsaw Sun Jun 23 00:59:59 1940 GMT = Sun Jun 23 02:59:59 1940 EET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Warsaw Wed May 31 21:59:59 1922 GMT = Wed May 31 23:59:59 1922 EET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Warsaw Wed May 31 22:00:00 1922 GMT = Wed May 31 23:00:00 1922 MET isdst=0 CHANGED NONEGG FIX ABBREV. > Europe/Warsaw Sun Jun 23 00:59:59 1940 GMT = Sun Jun 23 01:59:59 1940 MET isdst=0 ============================================================================================================================== CHANGED EGGERT COLLAPSE < America/Asuncion Mon Apr 1 03:00:00 1974 GMT = Sun Mar 31 23:00:00 1974 EST isdst=0 CHANGED EGGERT COLLAPSE < America/Asuncion Mon Apr 1 03:59:59 1974 GMT = Sun Mar 31 23:59:59 1974 EST isdst=0 CHANGED EGGERT COLLAPSE < America/Asuncion Mon Apr 1 04:00:00 1974 GMT = Mon Apr 1 00:00:00 1974 AST isdst=0 CHANGED EGGERT COLLAPSE > America/Asuncion Mon Apr 1 03:00:00 1974 GMT = Sun Mar 31 23:00:00 1974 AST isdst=0 CHANGED EGGERT COLLAPSE < America/Barbados Fri Jan 1 03:58:00 1932 GMT = Thu Dec 31 23:58:00 1931 BMT isdst=0 CHANGED EGGERT COLLAPSE < America/Barbados Fri Jan 1 03:59:59 1932 GMT = Thu Dec 31 23:59:59 1931 BMT isdst=0 CHANGED EGGERT COLLAPSE < America/Barbados Fri Jan 1 04:00:00 1932 GMT = Fri Jan 1 00:00:00 1932 AST isdst=0 CHANGED EGGERT COLLAPSE > America/Barbados Fri Jan 1 03:58:00 1932 GMT = Thu Dec 31 23:58:00 1931 AST isdst=0 CHANGED EGGERT COLLAPSE < America/Belize Mon Apr 1 05:52:48 1912 GMT = Sun Mar 31 23:52:48 1912 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/Belize Mon Apr 1 05:59:59 1912 GMT = Sun Mar 31 23:59:59 1912 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/Belize Mon Apr 1 06:00:00 1912 GMT = Mon Apr 1 00:00:00 1912 CST isdst=0 CHANGED EGGERT COLLAPSE > America/Belize Mon Apr 1 05:52:48 1912 GMT = Sun Mar 31 23:52:48 1912 CST isdst=0 CHANGED EGGERT COLLAPSE < America/Costa_Rica Sat Jan 15 05:36:00 1921 GMT = Fri Jan 14 23:36:00 1921 SJMT isdst=0 CHANGED EGGERT COLLAPSE < America/Costa_Rica Sat Jan 15 05:59:59 1921 GMT = Fri Jan 14 23:59:59 1921 SJMT isdst=0 CHANGED EGGERT COLLAPSE < America/Costa_Rica Sat Jan 15 06:00:00 1921 GMT = Sat Jan 15 00:00:00 1921 CST isdst=0 CHANGED EGGERT COLLAPSE > America/Costa_Rica Sat Jan 15 05:36:00 1921 GMT = Fri Jan 14 23:36:00 1921 CST isdst=0 CHANGED EGGERT COLLAPSE < America/El_Salvador Sat Jan 1 05:56:48 1921 GMT = Fri Dec 31 23:56:48 1920 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/El_Salvador Sat Jan 1 05:59:59 1921 GMT = Fri Dec 31 23:59:59 1920 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/El_Salvador Sat Jan 1 06:00:00 1921 GMT = Sat Jan 1 00:00:00 1921 CST isdst=0 CHANGED EGGERT COLLAPSE > America/El_Salvador Sat Jan 1 05:56:48 1921 GMT = Fri Dec 31 23:56:48 1920 CST isdst=0 CHANGED EGGERT COLLAPSE < America/Managua Sun Feb 16 05:00:00 1975 GMT = Sat Feb 15 23:00:00 1975 EST isdst=0 CHANGED EGGERT COLLAPSE < America/Managua Sun Feb 16 05:59:59 1975 GMT = Sat Feb 15 23:59:59 1975 EST isdst=0 CHANGED EGGERT COLLAPSE < America/Managua Sun Feb 16 06:00:00 1975 GMT = Sun Feb 16 00:00:00 1975 CST isdst=0 CHANGED EGGERT COLLAPSE > America/Managua Sun Feb 16 05:00:00 1975 GMT = Sat Feb 15 23:00:00 1975 CST isdst=0 CHANGED EGGERT COLLAPSE < America/Port-au-Prince Wed Jan 24 16:49:00 1917 GMT = Wed Jan 24 11:49:00 1917 PPMT isdst=0 CHANGED EGGERT COLLAPSE < America/Port-au-Prince Wed Jan 24 16:59:59 1917 GMT = Wed Jan 24 11:59:59 1917 PPMT isdst=0 CHANGED EGGERT COLLAPSE < America/Port-au-Prince Wed Jan 24 17:00:00 1917 GMT = Wed Jan 24 12:00:00 1917 EST isdst=0 CHANGED EGGERT COLLAPSE > America/Port-au-Prince Wed Jan 24 16:49:00 1917 GMT = Wed Jan 24 11:49:00 1917 EST isdst=0 CHANGED EGGERT COLLAPSE < America/Regina Fri Sep 1 06:58:36 1905 GMT = Thu Aug 31 23:58:36 1905 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/Regina Fri Sep 1 06:59:59 1905 GMT = Thu Aug 31 23:59:59 1905 LMT isdst=0 CHANGED EGGERT COLLAPSE < America/Regina Fri Sep 1 07:00:00 1905 GMT = Fri Sep 1 00:00:00 1905 MST isdst=0 CHANGED EGGERT COLLAPSE > America/Regina Fri Sep 1 06:58:36 1905 GMT = Thu Aug 31 23:58:36 1905 MST isdst=0 CHANGED EGGERT COLLAPSE < America/Santo_Domingo Sat Apr 1 16:40:00 1933 GMT = Sat Apr 1 11:40:00 1933 SDMT isdst=0 CHANGED EGGERT COLLAPSE < America/Santo_Domingo Sat Apr 1 16:59:59 1933 GMT = Sat Apr 1 11:59:59 1933 SDMT isdst=0 CHANGED EGGERT COLLAPSE < America/Santo_Domingo Sat Apr 1 17:00:00 1933 GMT = Sat Apr 1 12:00:00 1933 EST isdst=0 CHANGED EGGERT COLLAPSE > America/Santo_Domingo Sat Apr 1 16:40:00 1933 GMT = Sat Apr 1 11:40:00 1933 EST isdst=0 CHANGED EGGERT COLLAPSE < Asia/Amman Wed Dec 31 21:36:16 1930 GMT = Wed Dec 31 23:36:16 1930 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Amman Wed Dec 31 21:59:59 1930 GMT = Wed Dec 31 23:59:59 1930 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Amman Wed Dec 31 22:00:00 1930 GMT = Thu Jan 1 00:00:00 1931 EET isdst=0 CHANGED EGGERT COLLAPSE > Asia/Amman Wed Dec 31 21:36:16 1930 GMT = Wed Dec 31 23:36:16 1930 EET isdst=0 CHANGED EGGERT COLLAPSE < Asia/Damascus Wed Dec 31 21:34:48 1919 GMT = Wed Dec 31 23:34:48 1919 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Damascus Wed Dec 31 21:59:59 1919 GMT = Wed Dec 31 23:59:59 1919 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Damascus Wed Dec 31 22:00:00 1919 GMT = Thu Jan 1 00:00:00 1920 EET isdst=0 CHANGED EGGERT COLLAPSE > Asia/Damascus Wed Dec 31 21:34:48 1919 GMT = Wed Dec 31 23:34:48 1919 EET isdst=0 CHANGED EGGERT COLLAPSE < Asia/Jerusalem Mon Dec 31 21:39:00 1917 GMT = Mon Dec 31 23:39:00 1917 JMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Jerusalem Mon Dec 31 21:59:59 1917 GMT = Mon Dec 31 23:59:59 1917 JMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Jerusalem Mon Dec 31 22:00:00 1917 GMT = Tue Jan 1 00:00:00 1918 IST isdst=0 CHANGED EGGERT COLLAPSE > Asia/Jerusalem Mon Dec 31 21:39:00 1917 GMT = Mon Dec 31 23:39:00 1917 IST isdst=0 CHANGED EGGERT COLLAPSE < Asia/Nicosia Sun Nov 13 21:46:32 1921 GMT = Sun Nov 13 23:46:32 1921 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Nicosia Sun Nov 13 21:59:59 1921 GMT = Sun Nov 13 23:59:59 1921 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Nicosia Sun Nov 13 22:00:00 1921 GMT = Mon Nov 14 00:00:00 1921 EET isdst=0 CHANGED EGGERT COLLAPSE > Asia/Nicosia Sun Nov 13 21:46:32 1921 GMT = Sun Nov 13 23:46:32 1921 EET isdst=0 CHANGED EGGERT COLLAPSE < Asia/Shanghai Sat Dec 31 15:54:08 1927 GMT = Sat Dec 31 23:54:08 1927 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Shanghai Sat Dec 31 15:59:59 1927 GMT = Sat Dec 31 23:59:59 1927 LMT isdst=0 CHANGED EGGERT COLLAPSE < Asia/Shanghai Sat Dec 31 16:00:00 1927 GMT = Sun Jan 1 00:00:00 1928 CST isdst=0 CHANGED EGGERT COLLAPSE > Asia/Shanghai Sat Dec 31 15:54:08 1927 GMT = Sat Dec 31 23:54:08 1927 CST isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Azores Wed May 24 01:55:00 1911 GMT = Tue May 23 23:55:00 1911 HMT isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Azores Wed May 24 01:59:59 1911 GMT = Tue May 23 23:59:59 1911 HMT isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Azores Wed May 24 02:00:00 1911 GMT = Wed May 24 00:00:00 1911 ACT isdst=0 CHANGED EGGERT COLLAPSE > Atlantic/Azores Wed May 24 01:55:00 1911 GMT = Tue May 23 23:55:00 1911 ACT isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Stanley Tue Mar 12 03:51:00 1912 GMT = Mon Mar 11 23:51:00 1912 SMT isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Stanley Tue Mar 12 03:59:59 1912 GMT = Mon Mar 11 23:59:59 1912 SMT isdst=0 CHANGED EGGERT COLLAPSE < Atlantic/Stanley Tue Mar 12 04:00:00 1912 GMT = Tue Mar 12 00:00:00 1912 AST isdst=0 CHANGED EGGERT COLLAPSE > Atlantic/Stanley Tue Mar 12 03:51:00 1912 GMT = Mon Mar 11 23:51:00 1912 AST isdst=0 CHANGED EGGERT FIX ABBREV. < Europe/Brussels Sat Mar 1 22:00:00 1919 GMT = Sat Mar 1 22:00:00 1919 MET isdst=0 CHANGED EGGERT FIX ABBREV. < Europe/Brussels Sat Mar 1 22:59:59 1919 GMT = Sat Mar 1 22:59:59 1919 MET isdst=0 CHANGED EGGERT FIX ABBREV. > Europe/Brussels Sat Mar 1 22:00:00 1919 GMT = Sat Mar 1 22:00:00 1919 WET isdst=0 CHANGED EGGERT FIX ABBREV. > Europe/Brussels Sat Mar 1 22:59:59 1919 GMT = Sat Mar 1 22:59:59 1919 WET isdst=0 CHANGED EGGERT COLLAPSE < Pacific/Noumea Fri Jan 12 12:54:12 1912 GMT = Fri Jan 12 23:54:12 1912 LMT isdst=0 CHANGED EGGERT COLLAPSE < Pacific/Noumea Fri Jan 12 12:59:59 1912 GMT = Fri Jan 12 23:59:59 1912 LMT isdst=0 cHANGED EGGERT COLLAPSE < Pacific/Noumea Fri Jan 12 13:00:00 1912 GMT = Sat Jan 13 00:00:00 1912 NCST isdst=0 CHANGED EGGERT COLLAPSE > Pacific/Noumea Fri Jan 12 12:54:12 1912 GMT = Fri Jan 12 23:54:12 1912 NCST isdst=0

2 1

bug in zic for Rule and Zone changing simultaneously?
by Paul Eggert May 1, 1996

May 1, 1996

I found 23 bugs in the latest tz database. I enclose two detailed examples below, and a brief summary of all the bugs. It appears that zic has problems when applying Zone and Rule changes simultaneously. Example 1. The edited input is: # Rule NAME FROM TO TYPE IN ON AT SAVE LET Rule Falk 1985 max - Sep Sun>=9 0:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Stanley -3:00 Falk E%sT 1985 Sep 15 -4:00 Falk A%sT The zdump -v output is: Atlantic/Stanley Sun Sep 15 02:59:59 1985 GMT = Sat Sep 14 23:59:59 1985 EST isdst=0 Atlantic/Stanley Sun Sep 15 03:00:00 1985 GMT = Sat Sep 14 23:00:00 1985 AST isdst=0 Atlantic/Stanley Sun Sep 15 03:59:59 1985 GMT = Sat Sep 14 23:59:59 1985 AST isdst=0 Atlantic/Stanley Sun Sep 15 04:00:00 1985 GMT = Sun Sep 15 01:00:00 1985 ADT isdst=1 zdump claims that inhabitants of Stanley changed their clocks twice that night, when they changed them only once. The transition should have been from 1985-09-14 23:59:59 -0300 (EST) to 1985-09-15 00:00:00 -0400 (ADT), but zic applied `Zone' first, yielding 1985-09-14 23:00:00 -0200 (EDT), and then one hour later applied `Rule', yielding the proper time afterwards; but there's a one-hour period of incorrect times. Example 2. The input is: # Rule NAME FROM TO TYPE IN ON AT SAVE LET Rule Regina 1905 only - Sep 1 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Regina -6:58:36 - LMT 1905 Sep -7:00 Regina M%sT 1966 Apr 15 The zdump output is: America/Regina Fri Sep 1 06:58:35 1905 GMT = Thu Aug 31 23:59:59 1905 LMT isdst=0 America/Regina Fri Sep 1 06:58:36 1905 GMT = Thu Aug 31 23:58:36 1905 LMT isdst=0 America/Regina Fri Sep 1 06:59:59 1905 GMT = Thu Aug 31 23:59:59 1905 LMT isdst=0 America/Regina Fri Sep 1 07:00:00 1905 GMT = Fri Sep 1 00:00:00 1905 MST isdst=0 Again, there are two transitions where there should be one, and it's because the Zone was applied before the Rule, when they were meant to be applied simultaneously. In this case, the erroneous period is only 84 seconds long. Here is a list of the 23 bugs I found. Each line has the following columns: timezone name first time_t value in the erroneous period (1) first time_t value after the erroneous period is over (2) ctime applied to (1) ctime applied to (2) America/Asuncion 134017200 134020800 Sun Mar 31 23:00:00 1974 Mon Apr 1 00:00:00 1974 America/Barbados -1199217720 -1199217600 Thu Dec 31 23:58:00 1931 Fri Jan 1 00:00:00 1932 America/Belize -1822500432 -1822500000 Sun Mar 31 23:52:48 1912 Mon Apr 1 00:00:00 1912 America/Costa_Rica -1545071040 -1545069600 Fri Jan 14 23:36:00 1921 Sat Jan 15 00:00:00 1921 America/El_Salvador -1546279392 -1546279200 Fri Dec 31 23:56:48 1920 Sat Jan 1 00:00:00 1921 America/Juneau 436352400 436356000 Sun Oct 30 01:00:00 1983 Sun Oct 30 01:00:00 1983 America/Managua 161758800 161762400 Sat Feb 15 23:00:00 1975 Sun Feb 16 00:00:00 1975 America/Menominee 104914800 104918400 Sun Apr 29 01:00:00 1973 Sun Apr 29 03:00:00 1973 America/Port-au-Prince -1670483460 -1670482800 Wed Jan 24 11:49:00 1917 Wed Jan 24 12:00:00 1917 America/Regina -2030202084 -2030202000 Thu Aug 31 23:58:36 1905 Fri Sep 1 00:00:00 1905 America/Santo_Domingo -1159773600 -1159772400 Sat Apr 1 11:40:00 1933 Sat Apr 1 12:00:00 1933 America/Scoresbysund 354679200 354682800 Sun Mar 29 01:00:00 1981 Sun Mar 29 03:00:00 1981 Asia/Amman -1230776624 -1230775200 Wed Dec 31 23:36:16 1930 Thu Jan 1 00:00:00 1931 Asia/Damascus -1577931912 -1577930400 Wed Dec 31 23:34:48 1919 Thu Jan 1 00:00:00 1920 Asia/Istanbul 482792400 482796000 Fri Apr 19 23:00:00 1985 Sat Apr 20 01:00:00 1985 Asia/Jerusalem -1641003660 -1641002400 Mon Dec 31 23:39:00 1917 Tue Jan 1 00:00:00 1918 Asia/Nicosia -1518920008 -1518919200 Sun Nov 13 23:46:32 1921 Mon Nov 14 00:00:00 1921 Asia/Shanghai -1325491552 -1325491200 Sat Dec 31 23:54:08 1927 Sun Jan 1 00:00:00 1928 Atlantic/Azores -1849557900 -1849557600 Tue May 23 23:55:00 1911 Wed May 24 00:00:00 1911 Atlantic/Stanley -1824235740 -1824235200 Mon Mar 11 23:51:00 1912 Tue Mar 12 00:00:00 1912 Atlantic/Stanley 495601200 495604800 Sat Sep 14 23:00:00 1985 Sun Sep 15 01:00:00 1985 Europe/Brussels -1604282400 -1604278800 Sat Mar 1 22:00:00 1919 Sun Mar 2 00:00:00 1919 Pacific/Noumea -1829387148 -1829386800 Fri Jan 12 23:54:12 1912 Sat Jan 13 00:00:00 1912

1 0

Time Zone Request [forwarded with permission]
by ado April 24, 1996

April 24, 1996

I've forwarded the attached request with permission of the originator; replies can go to Ron or to the list as appropriate. --ado > ...Do you have any idea where I can find a tutorial regarding time > zones that includes a discussion of the international date line? Any > help will be greatly appreciated. Many thanks, Ron > > Ron Schodt > schodtr(a)infomail.infonet

1 0

/usr/share/lib/zoneinfo/europe
by allane＠parallax.co.uk April 23, 1996

April 23, 1996

Hi, The europe file as distributed by Sun Microsystems has, as far as I can tell, a small bug in the Europe/London zone. My diff is included below. At least the Sun seems to need the one hour offset in the RULES part instead of the GMTOFF. I have a small test program that shows the problem; if you are interested let me know. the problem only affects dates in the 1968-1971 period. Cheers, --- Allan ---------------------------------------------------------------------- Allan Engelhardt Consultant Parallax Solutions Ltd Stonecourt Siskin Drive Coventry CV3 4FJ Tel: [+44] (0)1203 514400 Fax: [+44] (0)1203 514401 E-Mail: Allan.Engelhardt(a)parallax.co.uk --- [% diff -c europe /usr/share/lib/zoneinfo/europe] --- *** europe Tue Apr 23 16:03:54 1996 --- /usr/share/lib/zoneinfo/europe Sat Jul 16 05:47:47 1994 *************** *** 661,667 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:00:37 - LMT 1847 Sep 22 0:00 GB-Eire %s 1968 Feb 18 2:00 ! 0:00 1:00 BST 1971 Oct 31 2:00 # Fixed -AE- 0:00 GB-Eire %s Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 # Dublin MT --- 661,667 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:00:37 - LMT 1847 Sep 22 0:00 GB-Eire %s 1968 Feb 18 2:00 ! 1:00 - BST 1971 Oct 31 2:00 0:00 GB-Eire %s Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 # Dublin MT

1 0

Krasnoyarsk timezone?
by Andrey V. Glukhov April 23, 1996

April 23, 1996

Dear sirs, I work with the zoneinfo format, supported by Linux and FreeBSD for two years, and I was sorrowed when I did not find Krasnoyarsk timezone in the latest release FreeBSD, where are mach more timezones. Are you support the zoneinfo package? Can you add the record below into the timezone database? # Krasnoyarsk # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/ Rule Krasnoyarsk 1970 max - Mar lastSun 2:00 1:00 D Rule Krasnoyarsk 1970 max - Sep lastSun 2:00 0 K # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Krasnoyarsk 7:00 Krasnoyarsk KRS%s I understand that Krasnoyarsk timezone is equal to registered Tomsk timezone now. Do the registration of Tomsk timezone hinder to registrate Krasnoyarsk timezone? Sincerely yours Andrey Glukhov

2 1

DST in EU, ex-USSR, Mongolia & software
by Chris Carrier April 21, 1996

April 21, 1996

I would like to ask a question about EU daylight time: since the directive defining the 'summer-time period' is for a limited number of years, when does the directive expire? Also, does anyone know what dates Russia and the rest of the CIS will be observing daylight time on this year? The World Almanac gave March-September, changing on the 4th Monday but I was thinking that Monday was probably in error and that I remember they were using EU dates in the mid-80s (source: English translation of PRAVDA) so they might be keeping DST until the end of October this year as well. About Mongolia. I just called the AT&T international operator and got a time of GMT+9 for Ulan Bator, and then asked if this time was valid throughout Mongolia and got an affirmative response. I presume GMT+9 means GMT+8 with DST, probably on whatever dates Russia is using. (I also have seen time maps with Mongolia in either one zone or split into three. I presume that both have been true at various times in their history.) Mongolia came up recently in sci.astro; there is a group going there for a total solar eclipse next month. About time changes being automatically built into software, VCRs, etc... I regard this as a very BAD idea, because DST rules change. (Thinking of many a system in the EU that is going to change back at the end of September and can't be programmed for the new directive...) Also there are places that don't use DST such as Arizona or the EST part of Indiana and groups and individuals who deliberately do not use local civil time.

3 2

Re: Comments on the EC summer time directive and a change request
by Dik.Winter＠cwi.nl April 20, 1996

April 20, 1996

> Proposals for the eighth directive were supposed to have been produced > by the Commission by 1 Jan 96. They have not yet appeared (I asked just > before Easter). As this 1 Jan 96 date was specified in the 7th directive > this also shows that the Commission can break the hard and fast laws > as it wishes. That is always the case with politicians, however they will create a new directive in time (say before the end of this year), otherwise we would get a huge outcry from companies that depend on it (like railway companies for their timeteables; the worst to them did occur when Germany did not yet know half 1976 whether they would go to DST in 1977 or not, all international timetables for the winter period 1976/77, which in part covered the DST period, where doubled allowing for both cases). There is hard pressure to have the rules more than one year in advance. > Things are slightly confused by the formal title of the Commission > still seeming to be `The Commission of the European Communities', > which I think harks back to the very early days when there were several > `Communities'. I think these were the Coal, Iron & Steel Community, > EURATOM, and I think one more. Eh, I think no. The successor of (in Dutch) EGKS (Coal and Steel Community) was the EEG (Economic Community); both singular in Dutch. Later it became EG (they dropped Economic), still singular, and now EU. So I do not know why the English use a plural; but you are late-comers. But is the formal English title not: "The Commision of the European Community"? > Enough of this non-tzone digression. Can I have Rule EC -> Rule EU please? Indeed. About VCR's knowing about DST, it is a bad idea. They should get their time from the time as it is installed (and shown by the VCR). If possible they should self-adjust to the time as it is broadcast. dik -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

1 0

Comments on the EC summer time directive and a change request
by peter＠aldie.co.uk April 20, 1996

April 20, 1996

Chris Carrier asks when the current (7th) summer time directive expires. Answer: the last year it covers is 1997. In response to Monty Solomon's exerpts from RISKS, the rule of `start on last Sunday in March, end on last Sunday in October' is specified in the directive, so it is more than just a de facto standard. Dik T. Winter is correct, the directive is a hard and fast law in the EU. However, remember that you are dealing with politicians here. If they feel like changing the hard and fast laws, they will, and the current 7th directive is living proof, with its change from September to October. Proposals for the eighth directive were supposed to have been produced by the Commission by 1 Jan 96. They have not yet appeared (I asked just before Easter). As this 1 Jan 96 date was specified in the 7th directive this also shows that the Commission can break the hard and fast laws as it wishes. Finally, I would like to request a change in the Europe file, changing the name of the Rule for the EU countries from EC to EU. This European entity has been called various things in English over the years, Common Market, European Economic Community (EEC), European Community (EC); but it is now almost universally referred to as the European Union. This trend will undoubtedy continue as more countries join. Things are slightly confused by the formal title of the Commission still seeming to be `The Commission of the European Communities', which I think harks back to the very early days when there were several `Communities'. I think these were the Coal, Iron & Steel Community, EURATOM, and I think one more. The Commission seem to be renaming themselves, at least on recent blurb I get from them, as the European Commission. This will allow them to steal the abbreviation EC for themselves now that the whole thing is called EU. We will then still get EC Directives, coming from the Commission. Enough of this non-tzone digression. Can I have Rule EC -> Rule EU please? Peter Ilieve peter(a)aldie.co.uk

1 0

Daylight Savings
by Monty Solomon April 19, 1996

April 19, 1996

FYI. Several excerpts from RISKS DIGEST 18.02, 18.03, 18.04, 18.05 ... ------------------------------ Date: Sun, 7 Apr 1996 13:31:38 -0400 From: Matt Welsh <mdw(a)CS.Cornell.EDU> Subject: De facto Daylight Savings At http://www.timing.se/Daylight.html there is a brief discussion of the rules for Daylight Savings Time changeovers for central Europe and the UK. At the end of the page it says: > NOTE: From autumn 1996 the rule of changing from standard time to > daylight time is changed. The new rule is valid for central Europe > including the UK is: > > Standard time to Daylight Saving LAST SUNDAY OF MARCH > Daylight Saving to Standard time LAST SUNDAY OF OCTOBER > > The rule is a "de facto standard," not a law. > > The switching occurs at 01:00 UTC for central Europe (Stockholm Paris etc.) > Local time that is at 02:00 STD to DST and 03:00 DST to STD. > (STD = Standard time, DST = Daylight Saving Time or Summer Time.) > > Note: The legal switching is steered by laws that state dates for a couple > of years. When a period ends a new law is issued that gives the dates for > the next years. > > The Laws do not state any general rule. Only dates for a couple years > each time. The "de facto rule" works, but there is no warranty it will > work forever! With all of our scrambling about to deal with the Year 2000 problem, shouldn't we be just as concerned with this inconsistency that arises yearly (especially if there are no 'hard and fast' laws/standards to dictate DST changeovers)? M. Welsh, mdw(a)cs.cornell.edu ------------------------------ Date: Wed, 10 Apr 1996 11:31:07 -0600 (MDT) From: wampler(a)cs.unm.edu Subject: Daylight Savings Time problem I was hit by a daylight savings time problem Monday, the day after the time changed here. My machine is running four different operating systems: Windows 95, Windows NT, OS/2, and Linux. Since I'd doing cross platform development, I usually boot at least two different OS's a day. Monday, I booted Windows 95 first. At startup, I was greeted by a polite messages asking if the time should be changed to DST. Fine. Time changed and correct. Later in the day, after booting both NT and Linux, I noticed the time was yet another hour ahead. Either NT or Linux (and I suspect NT, but can't confirm that) had also, but invisibly, changed to DST. After some thought, and a class discussion in the software engineering class I teach, I've concluded this is not an easy problem to solve. In this case, there were two basic contributing factors I can figure out. First, PCs keep the internal clock in local time. Not a good idea -- it should be Universal Time -- but reality. The problem is then that NT or Linux made the assumption it was the only OS on the machine, and was free to update the time. Unlike Win95, which could be polite about the change because it is normally a single user system, NT and Linux both could reasonably assume they don't normally get shut down each evening, and thus the silent time update (I'm guessing). It would be unreasonable to expect confirmation from an operator. In this case, however, the time update did come at boot time. It seems to me a better update policy for NT/Linux would be to silently update the time if the change happened while running, and require a confirmation if it happens at boot time. Not perfect, but better. I tried OS/2, also, and it just ignored the time change. Bruce E. Wampler, Ph.D., Adjunct Professor, Department of Computer Science, University of New Mexico wampler(a)cs.unm.edu http://www.cs.unm.edu/~wampler ------------------------------ Date: Tue, 9 Apr 1996 22:08:02 GMT From: Dik.Winter(a)cwi.nl (Dik T. Winter) Subject: Re: De facto Daylight Savings > At http://www.timing.se/Daylight.html there is a brief discussion > of the rules for Daylight Savings Time changeovers for central Europe > and the UK. At the end of the page it says: ... > > The rule is a "de facto standard," not a law. ... > With all of our scrambling about to deal with the Year 2000 problem, > shouldn't we be just as concerned with this inconsistency that arises > yearly (especially if there are no 'hard and fast' laws/standards to dictate > DST changeovers)? But there *are* 'hard and fast' laws that dictate DST changeovers. There is however *not* a law that dictates this far into the future but only for a few coming years. (Note that these laws, EU directives, are made up far in advance. It was already known a few years ago that the EU would change the rule this year.) It appears not to be very advisable to cast changeover dates in concrete. It is up to the software to deal with this flexibility and Andrew Olson's timezone package deals very well with it. (And some software does not handle it well at all. Most annoying was a bug in SGI's software which thought the last Sunday in September last year was October 1, and so switched out of DST one week late. Exactly the same bug stroke again this time when the software thought that the last Sunday of March was March 24, and so switched into DST one week early. Surprising that the bug was not fixed in that half year.) dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ ------------------------------ Date: Thu, 11 Apr 1996 18:45:14 -0400 From: "John F. Whitehead" <jfw(a)wral-tv.com> Subject: Re: Daylight Savings Time problem: Netscape 2.* reload There has been another side effect of the daylight savings time change, with the Netscape Navigator browser: caches have incorrect times and no longer work properly for documents that change frequently. Netscape Navigator version 2.x for Windows and Unix platforms is an hour off in its cache-file handling. If a user tries to reload a page that has changed within the last hour, the browser still thinks its cached version is more up to date and won't retrieve the new version. (After an hour, this is no longer an issue.) This has been a problem with news organizations (such as ours), chat/bulletin boards, and java applets that need to be updated frequently. Netscape's "force reload" procedure (shift key + reload button) doesn't always work either: the only solution is to flush the memory and disk caches before a reload, or to set them to size zero. Netscape has made no official statement, but apparently has said the bug won't be fixed in the next version of the software (2.1) but in the one after that (3.0 (Atlas)). The Macintosh version does not suffer from this bug, nor do versions 1.x, or browsers from other manufacturer. The risk (aside from the obvious one related to programming for time changes) is trusting that a market-leader software company is going to have bug-free software. John F. Whitehead OnLine Technical Director 919-821-8605 jfw(a)wral-tv.com http://www.wral-tv.com [This problem was also reported by CurtAkin(a)aol.com and Prentiss Riddle <riddle(a)is.rice.edu> -- next message. PGN] ------------------------------ Date: Mon, 15 Apr 1996 09:14:54 -0500 (CDT) From: Prentiss Riddle <riddle(a)is.rice.edu> Subject: Another Daylight Saving Time problem: Netscape 2.* reload [...] One workaround is said to be to run Netscape in California time, e.g. under Unix: setenv TZ PDT ; netscape & Defying the RISKS tradition of intoning that "the risks are obvious", one could draw the following lessons: -- Time-dependent functions should be tested using multiple time zones and both DST- and non-DST dates. -- In networked applications, local time issues can cause more than just local problems. Prentiss Riddle <riddle(a)rice.edu> http://is.rice.edu/~riddle RiceInfo Administrator, Rice University ------------------------------ Date: Thu, 11 Apr 1996 16:20:49 -0400 (EDT) From: beaton1(a)server.uwindsor.ca (Lorne Beaton) Subject: Another Daylight Savings Time risk: billing My university recently (ca. January 1, after a testing period of about a month) instituted a new dialup service, for which students and faculty are charged 75 cents per hour peak and 60 cents off-peak. A couple of days ago I logged on and saw something like the following in my logon message: > Charges THIS month to date 500 minutes for a cost of $ 49.59 > Charges LAST month (total) 2089 minutes for a cost of $ 24.76 (Note that these aren't the exact figures, but you get the idea.) Needless to say I was consternated. After complaining to the admins, I learned that the billing discrepancy arose from the change to Daylight time. Night owl that I am, I happened to be logged in at the exact moment that 2:00 a.m. EST became 3:00 a.m. EDT. Needless to say, this was the first time they had dealt with the changeover. Happily, the problem has since been fixed, but the risk is self-evident. Lorne Beaton <beaton1(a)server.uwindsor.ca> ------------------------------ Date: Tue, 16 Apr 1996 10:23:50 -0700 From: phaedrus(a)halcyon.com (Mark Phaedrus) Subject: Re: Daylight Savings Time problem: Netscape 2.* (Whitehead, R 18 04) Actually, Netscape has publically announced that "We are preparing to release Netscape Navigator 2.02 in the next two weeks to fix this problem." (Source: <URL:http://home.netscape.com/misc/DST_err.html>.) They also give one other, rather unsatisfactory workaround (besides clearing or zeroing your disk cache, or setting the time-zone variable correctly): set your machine's clock back an hour... [Also noted by Prentiss Riddle <riddle(a)is.rice.edu> and "J. David Stanton, Jr." <jstanton(a)coin.state.pa.us>. PGN] ------------------------------

1 0

tzdata96f.tar.gz
by ado April 19, 1996

April 19, 1996

The file tzdata96f.tar.gz is now available for anonymous ftp from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory: -rw-r--r-- 1 ado wheel 73553 Apr 19 15:12 tzdata96f.tar.gz The only changes are to the "northamerica" file; the time zone abbreviation for Denver is corrected to MST (and MDT), and the comments for Mexico have been updated. Changes to Bangalore, the People's Republic of China, and Chuuk/Truk may follow. --ado

2 1