- tz - lists.iana.org

Re: old time zones (europe)
by Dik.Winter＠cwi.nl Oct. 25, 1995

Oct. 25, 1995

> There are some inconsistencies in the file: Indeed, but others than you are seeing. > Also, according to the Germany entry and to my vague memory, Germany > introduced DST in 1980 rather than 1981, which put pressure on all the > small ES countries to come to some kind of harmonisation. The file correctly notes that Germany introduced it in 1980 and Switzerland, Austria and Liechtenstein in 1981 (at least in version 95i). However there is a inconsistency in one of the lines for Luxembourg. It states: 1:00 Belgium MET%s 1979 while a similar line for Brussels states 1977. Should be changed in Luxembourg (the BeNeLux switched to "EC" rules in 1977). Further with respect to France. The file states that Shanks has no data on summertime in France in 1975 but that there is a note that states that summertime has been used. I just checked the Dutch railway timetable for summer 1975 and it says nothing about summer- time in France, so I presume no summertime. (In a later year, when it was unsure whether Germany would already switch to summer time until a very late stage the Dutch railway timetable came with double tables when Germany was involved. One for when summertime would be introduced and one when it would not be introduced.) The timetables are pretty good to establish in what years summertime was used; not for the exact starting and ending dates. dik -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik(a)cwi.nl

1 0

Re: old time zones (europe)
by bs＠cs.uni-sb.de Oct. 25, 1995

Oct. 25, 1995

Rolf-Martin Mantel writes: [...] > Also, according to the Germany entry and to my vague memory, Germany > introduced DST in 1980 rather than 1981, which put pressure on all the > small ES countries to come to some kind of harmonisation. That's correct. I have here a paper from the PTB (Physikalisch-Technische Bundesanstalt, Braunschweig - the responsible "time authority" for Germany) which states: 1980: Apr. 6 to Sept. 28 (!!) 1981: Mar. 29 to Sept. 27 ... Bernard Sieloff U of Saarbruecken, Germany

1 0

old time zones (europe)
by Mr. Rolf-Martin Mantel Oct. 25, 1995

Oct. 25, 1995

There are some inconsistencies in the file: 1.) # ... # The only [current nonmember using EU rules] I can speak for is Estonia, # which uses EU dates but not at 01:00 GMT, they use midnight GMT. I don't # think they know yet what they will do from 1996 onwards. # ... In the individual entries, it is clearly pointed out that Switzerland, Liechtenstein and Norway use EU rules since 1981 or 82. # ...the European time rules are...standardized since 1981, when # most European coun[tr]ies started DST. Before that year, only # a few countries (UK, France, Italy) had DST, each according # to own national rules. In 1981, however, DST started on # 'Apr firstSun', and not on 'Mar lastSun' as in the following # years... # But also since 1981 there are some more national exceptions # than listed in 'europe': Switzerland, for example, joined DST # one year later, Denmark ended DST on 'Oct 1' instead of 'Sep # lastSun' in 1981---I don't know how they handle now. # Also, according to the Germany entry and to my vague memory, Germany introduced DST in 1980 rather than 1981, which put pressure on all the small ES countries to come to some kind of harmonisation. Rolf

1 0

Re: Irish timezone error?
by ado Oct. 23, 1995

Oct. 23, 1995

> In Ireland, we change from BST to GMT on the 4th Sunday in October... > Is there a...version of these timezone files available, or a program > which would generate them properly? (I'm using Linux 1.3) The files available from anonymous ftp from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory... -rw-r--r-- 1 ado 65805 Oct 13 13:24 tzcode95e.tar.gz -rw-r--r-- 1 ado 69404 Sep 26 10:44 tzdata95i.tar.gz ...reflect a fourth-Sunday-in-October switch in Dublin. --ado

1 0

Irish timezone error?
by Colm Buckley Oct. 23, 1995

Oct. 23, 1995

Hmm - I wonder have you seen this before? In Ireland, we change from BST to GMT on the 4th Sunday in October - ie: an appropriate TZ would be GMT0BST-1,M3.5.0/1,M10.4.0/1 (I'm not 100% certain that the changeover time is 1:00am; it could be 2:00). Anyway, the standard "Eire", "GB-Eire" and "Europe/Dublin" all seem to use M10.5.0 as the change-back date. Is there a newer version of these timezone files available, or a program which would generate them properly? (I'm using Linux 1.3) Thanks in advance, Colm. -- Colm Buckley | EMail: Colm.Buckley(a)tcd.ie Phone: (+353 1) 6082336 Computer Science Dept | WWW: http://isg.cs.tcd.ie/cbuckley/ Trinity College | finger cbuckley(a)isg.cs.tcd.ie for more info. Dublin 2, Ireland | "Too many windows, not enough brain."

1 0

Re: timezone stuff on 64 bit machines
by ado Oct. 23, 1995

Oct. 23, 1995

>> The fix is to use the fact that--at least for now--the calendar operates on >> a grand 2800-year cycle: any set of 2800 consecutive years contains exactly >> 1,022,679 days. A bit of modular arithmetic will get us where we want to be. > > To me this calls attention to a fundamental design flaw: any > computation of daylight savings time that involves looping a > billion times, or even a thousand, cannot be right. Under what > circumstances does this happen? The attached might be used to avoid thousands of loops. --ado SCCS/s.localtime.c: 7.45 vs. 7.48 *** 7.45/localtime.c Mon Oct 23 10:48:43 1995 --- 7.48/localtime.c Mon Oct 23 10:48:45 1995 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.45"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.48"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1173,1191 **** if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; y = EPOCH_YEAR; ! if (days >= 0) ! for ( ; ; ) { ! yleap = isleap(y); ! if (days < (long) year_lengths[yleap]) ! break; ! ++y; ! days = days - (long) year_lengths[yleap]; ! } ! else do { ! --y; ! yleap = isleap(y); ! days = days + (long) year_lengths[yleap]; ! } while (days < 0); tmp->tm_year = y - TM_YEAR_BASE; tmp->tm_yday = (int) days; ip = mon_lengths[yleap]; --- 1173,1190 ---- if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; y = EPOCH_YEAR; ! #define LEAPS_THRU_END_OF(y) ((y) / 4 - (y) / 100 + (y) / 400) ! while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) { ! register int newy; ! ! newy = y + days / DAYSPERNYEAR; ! if (days < 0) ! --newy; ! days -= (newy - y) * DAYSPERNYEAR + ! LEAPS_THRU_END_OF(newy - 1) - ! LEAPS_THRU_END_OF(y - 1); ! y = newy; ! } tmp->tm_year = y - TM_YEAR_BASE; tmp->tm_yday = (int) days; ip = mon_lengths[yleap];

1 0

Re: proposed fixes for Chile etc.
by Dik.Winter＠cwi.nl Oct. 22, 1995

Oct. 22, 1995

+ # Europa + # uninhabited + I find this amusing. Perhaps it is better to make it Ile Europe? dik -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik(a)cwi.nl

2 1

proposed zic.c change to cope with "32 < sizeof (time_t)"
by ado Oct. 22, 1995

Oct. 22, 1995

Attached is a proposed change to let zic.c cope gracefully when 32 < sizeof (time_t) I'll make it part of the ftpable stuff if nobody squawks in the next week. --ado SCCS/s.zic.c: 7.50 vs. 7.51 *** 7.50/zic.c Sat Oct 21 05:58:46 1995 --- 7.51/zic.c Sat Oct 21 05:58:47 1995 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.50"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.51"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 567,594 **** ifree(toname); } static void setboundaries P((void)) { register time_t bit; ! register int bii; for (bit = 1; bit > 0; bit <<= 1) ! continue; ! if (bit == 0) { /* time_t is an unsigned type */ ! tt_signed = FALSE; ! min_time = 0; ! max_time = ~(time_t) 0; if (sflag) ! max_time >>= 1; } else { ! tt_signed = TRUE; ! min_time = bit; ! max_time = bit; ! ++max_time; ! max_time = -max_time; if (sflag) ! min_time = 0; } min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; --- 567,613 ---- ifree(toname); } + #define MAX_BITS_IN_FILE 32 + static void setboundaries P((void)) { register time_t bit; ! register int nbits; ! register int bii; + nbits = 0; for (bit = 1; bit > 0; bit <<= 1) ! ++nbits; ! tt_signed = (bit != 0); ! if (tt_signed) ! ++nbits; ! if (tt_signed) { ! if (nbits <= MAX_BITS_IN_FILE) { ! min_time = bit; ! max_time = bit; ! ++max_time; ! max_time = -max_time; ! } else { ! max_time = 1; ! max_time <<= (MAX_BITS_IN_FILE - 1); ! --max_time; ! min_time = max_time; ! --min_time; ! } if (sflag) ! min_time = 0; } else { ! min_time = 0; ! if (nbits <= MAX_BITS_IN_FILE) ! max_time = ~(time_t) 0; ! else { ! max_time = 1; ! max_time <<= MAX_BITS_IN_FILE; ! --max_time; ! } if (sflag) ! max_time >>= 1; } min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year;

2 1

proposed fixes for Chile etc.
by Paul Eggert Oct. 22, 1995

Oct. 22, 1995

I checked with Shanks, and he agrees with Eduardo Krell that Chile switches on the second Saturday at 24:00. I had transcribed Shanks's Chilean data incorrectly -- sorry about that. Here is a proposed patch that fixes the above bug, plus makes the following political changes that I have been accumulating: * Add an entry (or at least a comment) for every area that the ISO gives a country code to, even the uninhabited ones like Bassas da India. Report which areas are uninhabited (and thus whose time zone rules are pretty much undefined). * The Pacific Island Trust Territories have split up. Add entries for Pacific/Saipan (capital of N Mariana Is) and Pacific/Kosrae (now part of Micronesia). * ``Samoa'' is really two areas: American Samoa (US territory) and Western Samoa (an independent country). Add new entries Pacific/Pago_Pago and Pacific/Apia, one for each Samoa. Link the former to Pacific/Samoa for backward compatibility. Move the Samoan entries from northamerica to australasia, where they really belong. * Similarly, ``The Virgin Islands'' are really two possessions: the American Virgins and the British Virgins. Add new entries America/St_Thomas and America/Tortola, one for each possession. Link the former to America/Virgin for backward compatibility. * Aruba is considered to be a separate part of the Dutch realm from the Netherlands Antilles, so add an entry America/Aruba. * The main town in Mayotte is Mamoutzou, not Dzaoudzi. =================================================================== RCS file: RCS/africa,v retrieving revision 1995.8 retrieving revision 1995.8.0.1 diff -c -r1995.8 -r1995.8.0.1 *** africa 1995/09/21 15:26:25 1995.8 --- africa 1995/10/22 04:34:01 1995.8.0.1 *************** *** 118,123 **** --- 118,126 ---- 0:52 - LMT 1911 May 26 # Luanda Mean Time 1:00 - CAT + # Bassas da India + # uninhabited + # Benin # Whitman says they switched to 1:00 in 1946, not 1934; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 248,253 **** --- 251,259 ---- 2:35 - AAMT 1936 May 5 # Addis Ababa MT 3:00 - EAT + # Europa + # uninhabited + # Gabon # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Libreville 0:37:48 - LMT 1912 *************** *** 273,278 **** --- 279,287 ---- Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s + # Glorioso Is + # uninhabited + # Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Conakry -0:54:52 - LMT 1912 *************** *** 286,291 **** --- 295,303 ---- 1:00 - CAT 1975 0:00 - WAT + # Juan de Nova + # uninhabited + # Kenya # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # Shanks says the transition to 2:45 was in 1940, but it must have been 1948. *************** *** 396,402 **** # Mayotte # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Mayotte 3:01:08 - LMT 1911 Jul # Dzaoudzi 3:00 - EAT # Morocco --- 408,414 ---- # Mayotte # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou 3:00 - EAT # Morocco *************** *** 452,458 **** # Reunion # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # St Denis 4:00 - SMT # Rwanda --- 464,470 ---- # Reunion # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis 4:00 - SMT # Rwanda *************** *** 550,555 **** --- 562,570 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lome 0:04:52 - LMT 1893 0:00 - WAT + + # Tromelin + # uninhabited # Tunisia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S =================================================================== RCS file: RCS/antarctica,v retrieving revision 1995.9 retrieving revision 1995.9.0.1 diff -c -r1995.9 -r1995.9.0.1 *** antarctica 1993/11/22 20:23:15 1995.9 --- antarctica 1995/10/22 04:34:01 1995.9.0.1 *************** *** 9,19 **** # South Orkney Is # South Shetland Is - # Amsterdam Island # Bouvet ! # Crozet Is ! # Heard and McDonald Is ! # Kerguelen Is ! # St Paul Island # Peter I Island # Scott Island --- 9,25 ---- # South Orkney Is # South Shetland Is # Bouvet ! # uninhabited ! ! # French Southern and Antarctic Lands (no indigenous inhabitants) include ! # Amsterdam Island ! # Crozet Is ! # Kerguelen Is ! # St Paul Island ! ! # Heard Island, McDonald Is ! # uninhabited ! # Peter I Island # Scott Island =================================================================== RCS file: RCS/asia,v retrieving revision 1995.8 retrieving revision 1995.8.0.1 diff -c -r1995.8 -r1995.8.0.1 *** asia 1995/09/21 15:26:27 1995.8 --- asia 1995/10/22 04:34:01 1995.8.0.1 *************** *** 723,728 **** --- 723,731 ---- 2:00 Zion I%sT # This will undoubtedly change soon. + # Paracel Is + # no information + # Philippines # Howse writes (p 162) that until 1844 the Philippines kept American date. # The rest of this data is from Shanks. *************** *** 762,767 **** --- 765,773 ---- 7:20 - SGT 1950 7:30 - SGT 1982 May 8:00 - SGT + + # Spratly Is + # no information # Sri Lanka # Zone NAME GMTOFF RULES FORMAT [UNTIL] =================================================================== RCS file: RCS/australasia,v retrieving revision 1995.6 retrieving revision 1995.6.0.1 diff -c -r1995.6 -r1995.6.0.1 *** australasia 1995/08/29 00:46:56 1995.6 --- australasia 1995/10/22 04:34:01 1995.6.0.1 *************** *** 143,150 **** --- 143,155 ---- 7:00 - JVT # # Ashmore Is, Cartier + # no indigenous inhabitants; only seasonal caretakers # no information; probably like Australia/Perth # + # Coral Sea Is + # no indigenous inhabitants; only meteorologists + # no information + # # Macquarie, Manihiki, Penrhyn, Rakehanga # no information *************** *** 184,197 **** 10:00 - GST # Howland, Baker ! # no information; probably like Pacific/Samoa # Jarvis ! # no information; probably like Pacific/Kiritimati # Johnston # no information; probably like Pacific/Honolulu # Kiribati # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki --- 189,207 ---- 10:00 - GST # Howland, Baker ! # uninhabited since World War II ! # no information; was probably like Pacific/Pago_Pago # Jarvis ! # uninhabited since 1958 ! # no information; was probably like Pacific/Kiritimati # Johnston # no information; probably like Pacific/Honolulu + # Kingman + # uninhabited + # Kiribati # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki *************** *** 203,208 **** --- 213,248 ---- -10:40 - LIT 1979 Oct # Line Is Time -10:00 - THT + # N Mariana Is + # Zone NAME GMTOFF RULES FORMAT [UNTIL] + Zone Pacific/Saipan 9:43:00 - LMT 1901 + 9:00 - PLT 1969 Oct + 10:00 - GST + + # Marshall Is + # Zone NAME GMTOFF RULES FORMAT [UNTIL] + Zone Pacific/Majuro 11:24:48 - LMT 1901 + 11:00 - NCST 1969 Oct + 12:00 - NZST + Zone Pacific/Kwajalein 11:09:20 - LMT 1901 + 11:00 - NCST 1969 Oct + -12:00 - KJT 1993 Aug 20 + 12:00 - NZST + + # Micronesia + # Zone NAME GMTOFF RULES FORMAT [UNTIL] + Zone Pacific/Yap 9:12:32 - LMT 1901 # Colonia + 9:00 - PLT 1969 Oct + 10:00 - GST + Zone Pacific/Truk 10:07:08 - LMT 1901 + 10:00 - GST 1978 Oct + 11:00 - NCST + Zone Pacific/Ponape 10:32:52 - LMT 1901 # Kolonia + 11:00 - NCST + Zone Pacific/Kosrae 10:51:56 - LMT 1901 + 11:00 - NCST 1969 Oct + 12:00 - NZST + # Nauru # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Nauru 11:07:40 - LMT 1921 Jan 15 # Uaobe *************** *** 273,303 **** 11:12 - NMT 1951 11:30 - NRFT - # Pacific Islands Trust Territories - # Zone NAME GMTOFF RULES FORMAT [UNTIL] - Zone Pacific/Majuro 11:24:48 - LMT 1901 - 11:00 - NCST 1969 Oct - 12:00 - NZST - Zone Pacific/Kwajalein 11:09:20 - LMT 1901 - 11:00 - NCST 1969 Oct - -12:00 - KJT 1993 Aug 20 - 12:00 - NZST - Zone Pacific/Truk 10:07:08 - LMT 1901 - 10:00 - GST 1978 Oct - 11:00 - NCST - Zone Pacific/Ponape 10:33:00 - LMT 1901 - 11:00 - NCST - Zone Pacific/Yap 9:12:24 - LMT 1901 - 9:00 - PLT 1969 Oct - 10:00 - GST - # Palau # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Palau 8:57:56 - LMT 1901 # Koror 9:00 - PLT # Palmyra ! # no information; probably like Pacific/Kiritmati # Papua New Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 313,325 ---- 11:12 - NMT 1951 11:30 - NRFT # Palau # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Palau 8:57:56 - LMT 1901 # Koror 9:00 - PLT # Palmyra ! # uninhabited since World War II; was probably like Pacific/Kiritmati # Papua New Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 310,315 **** --- 332,351 ---- Zone Pacific/Pitcairn -8:40:20 - LMT 1901 # Adamstown -8:30 - PIT + # American Samoa + Zone Pacific/Pago_Pago 12:37:12 - LMT 1879 Jul 5 + -11:22:48 - LMT 1911 + -11:30 - SST 1950 + -11:00 - NST 1967 Apr # N=Nome + -11:00 - BST 1983 Nov 30 # B=Bering + -11:00 - SST # S=Samoa + + # W Samoa + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 + -11:26:56 - LMT 1911 + -11:30 - SST 1950 + -11:00 - SST + # Solomon Is # excludes Bougainville, for which see Papua New Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 353,361 **** Zone Pacific/Wallis 12:15:20 - LMT 1901 12:00 - NZST - # Western Samoa - # See Pacific/Samoa in the `northamerica' file, of all places. - ############################################################################### # NOTES --- 389,394 ---- *************** *** 405,411 **** # - 9:00 GBT Gambier* # - 8:30 PIT Pitcairn* # ! # See the `northamerica' file for Hawaii and Samoa. # See the `southamerica' file for Easter I and the Galapagos Is. # # See the `africa' file for Zone naming conventions. --- 438,444 ---- # - 9:00 GBT Gambier* # - 8:30 PIT Pitcairn* # ! # See the `northamerica' file for Hawaii. # See the `southamerica' file for Easter I and the Galapagos Is. # # See the `africa' file for Zone naming conventions. *************** *** 780,788 **** # respect to the International Date Line, to rejoin its fellow islands, # going from 11:59 p.m. Thursday to 12:00 m. Saturday in a blink. ! # Pacific Islands Trust Territories # Howse writes (p 162) ``The Spaniards, on the other hand, reached the # Philippines and the Ladrones from America,'' and implies that the Ladrones # (now called the Marianas) kept American date for quite some time. # Ignore this for now, as we have no hard data. See also Asia/Manila. --- 813,828 ---- # respect to the International Date Line, to rejoin its fellow islands, # going from 11:59 p.m. Thursday to 12:00 m. Saturday in a blink. ! # N Mariana Is, Guam # Howse writes (p 162) ``The Spaniards, on the other hand, reached the # Philippines and the Ladrones from America,'' and implies that the Ladrones # (now called the Marianas) kept American date for quite some time. # Ignore this for now, as we have no hard data. See also Asia/Manila. + + # Samoa + + # Howse writes that in 1879 the King of Samoa decided to change + # ``the date in his kingdom from the Antipodean to the American system, + # ordaining -- by a masterpiece of diplomatic flattery -- that + # the Fourth of July should be celebrated twice in that year.'' =================================================================== RCS file: RCS/backward,v retrieving revision 1995.3 retrieving revision 1995.3.0.1 diff -c -r1995.3 -r1995.3.0.1 *** backward 1995/07/02 23:19:25 1995.3 --- backward 1995/10/22 04:34:01 1995.3.0.1 *************** *** 3,8 **** --- 3,9 ---- # This file provides links between current names for time zones # and their old names. Many names changed in late 1993. + Link America/St_Thomas America/Virgin Link Australia/Canberra Australia/ACT Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW *************** *** 51,56 **** --- 52,58 ---- Link America/Shiprock Navajo Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT + Link Pacific/Pago_Pago Pacific/Samoa Link Asia/Shanghai PRC Link Europe/Warsaw Poland Link Europe/Lisbon Portugal *************** *** 70,76 **** Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific ! Link Pacific/Samoa US/Samoa Link Etc/UTC UTC Link Etc/Universal Universal Link Europe/Moscow W-SU --- 72,78 ---- Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific ! Link Pacific/Pago_Pago US/Samoa Link Etc/UTC UTC Link Etc/Universal Universal Link Europe/Moscow W-SU =================================================================== RCS file: RCS/northamerica,v retrieving revision 1995.9 retrieving revision 1995.9.0.1 diff -c -r1995.9 -r1995.9.0.1 *** northamerica 1995/09/26 14:43:26 1995.9 --- northamerica 1995/10/22 04:34:01 1995.9.0.1 *************** *** 157,176 **** -5:00 - EST 1973 -5:00 US E%sT - # Samoa just changes names. No DST, per Naval Observatory. - # - # Howse writes that in 1879 the King of Samoa decided to change - # ``the date in his kingdom from the Antipodean to the American system, - # ordaining -- by a masterpiece of diplomatic flattery -- that - # the Fourth of July should be celebrated twice in that year.'' - - Zone Pacific/Samoa 12:37:12 - LMT 1879 Jul 5 - -11:22:48 - LMT 1911 - -11:30 - SST 1950 - -11:00 - NST 1967 Apr # N=Nome - -11:00 - BST 1983 Nov 30 # B=Bering - -11:00 - SST # S=Samoa - Zone Pacific/Midway -11:49:28 - LMT 1901 -11:00 - NST 1967 Apr # N=Nome -11:00 - BST 1983 Nov 30 # B=Bering --- 157,162 ---- *************** *** 193,199 **** -10:00 - HST # Navassa ! # no information; probably like America/New_York # Old names, for S5 users --- 179,185 ---- -10:00 - HST # Navassa ! # uninhabited # Old names, for S5 users *************** *** 730,736 **** -5:00 - EST # Clipperton ! # no information # Costa Rica # Shanks gives some very odd dates for 1991, and stops there. --- 716,722 ---- -5:00 - EST # Clipperton ! # uninhabited # Costa Rica # Shanks gives some very odd dates for 1991, and stops there. *************** *** 949,955 **** -5:00 - EST 1979 Apr 29 2:00 -5:00 US E%sT ! # Virgin Is (British and US) # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone America/Virgin -4:19:44 - LMT 1911 Jul # Charlotte Amalie -4:00 - AST --- 935,946 ---- -5:00 - EST 1979 Apr 29 2:00 -5:00 US E%sT ! # British Virgin Is ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town ! -4:00 - AST ! ! # Virgin Is # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie -4:00 - AST =================================================================== RCS file: RCS/southamerica,v retrieving revision 1995.4 retrieving revision 1995.4.0.1 diff -c -r1995.4 -r1995.4.0.1 *** southamerica 1995/07/03 17:26:22 1995.4 --- southamerica 1995/10/22 04:34:01 1995.4.0.1 *************** *** 107,112 **** --- 107,118 ---- -4:00 Arg A%sT 1969 Oct 5 -3:00 Arg AR%sT + # Aruba + # Zone NAME GMTOFF RULES FORMAT [UNTIL] + Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad + -4:30 - NAST 1965 # Netherlands Antilles + -4:00 - AST + # Bolivia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/La_Paz -4:32:36 - LMT 1890 *************** *** 199,219 **** # Chile ! # From Guy Harris: ! # The OAG lists October 11, 1987 and March 12, 1988 as the starting and ! # ending dates, giving them as "estimated date(s) based on previous year." ! ! # From Bob Devine (January 28, 1988): ! # Chile has had 2nd Sunday in October to 2nd Sunday in March DST since 1977. ! # Switch is at midnight. OAG is right. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1918 only - Sep 1 0:00 1:00 D Rule Chile 1919 only - Jul 2 0:00 0 S Rule Chile 1927 1931 - Sep 1 0:00 1:00 D Rule Chile 1928 1932 - Apr 1 0:00 0 S ! Rule Chile 1969 max - Oct Sun>=8 0:00 1:00 D ! Rule Chile 1970 max - Mar Sun>=8 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:40 - LMT 1890 -4:43 - SMT 1910 # Santiago Mean Time --- 205,221 ---- # Chile ! # From Eduardo Krell (1995-10-19): ! # The law says to switch to DST at midnight [24:00] on the second SATURDAY ! # of October.... The law is the same for March and October. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1918 only - Sep 1 0:00 1:00 D Rule Chile 1919 only - Jul 2 0:00 0 S Rule Chile 1927 1931 - Sep 1 0:00 1:00 D Rule Chile 1928 1932 - Apr 1 0:00 0 S ! Rule Chile 1969 max - Oct Sun>=9 0:00 1:00 D ! Rule Chile 1970 max - Mar Sun>=9 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:40 - LMT 1890 -4:43 - SMT 1910 # Santiago Mean Time *************** *** 334,340 **** -2:00 - FST # South Sandwich Is ! # no information # Suriname # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 336,342 ---- -2:00 - FST # South Sandwich Is ! # uninhabited # Suriname # Zone NAME GMTOFF RULES FORMAT [UNTIL]

1 0

Chile's time zone data wrong
by ekrell＠tandem.cl Oct. 19, 1995

Oct. 19, 1995

Hi, I don't know if you're the right person, but your name is in Sun's /usr/share/lib/zoneinfo/southamerica file under Solaris 2.4 I wanted you to know that the rule for Chile is incorrect. This year, we switched to DST at midnight on Saturday, October 14th, but the rules in that file made our Suns switch to DST a week earlier. The reason for the discrepancy is that the rules in the file specify to switch to DST at 0:00 the second sunday of October. This year, October 1st was a sunday, so the second Sunday was October 8th. That's when our Suns switched to DST. However, the law says to switch to DST at midnight on the second SATURDAY of October, which is not the same as 0:00 on the second sunday of October. In fact, this year the bug showed up because October 1st was a Sunday... May I suggest to change the specification to Sun>=9 ? Eduardo Krell R&D Manager Tandem Chile S.A. Santiago ekrell(a)tandem.cl

2 1

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

> It fixed that problem form my point of view -- meaning it comes out > of that loop. Now there's a hang in outzone() in zic.c. At line 1439 > it loops over every year once again. Here the solution may be in the "setboundaries" code in "zic.c". Since time zone files only encode four characters (32 bits) worth of time_t values, min_time and max_time (and min_year and max_year) might be limited. A cheap way to hot-wire things for testing purposes is to add the lines min_time = 0; max_time = 0x7fffffffL; just above the min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; lines in "setboundaries" This begs the question of whether the format of time zone files would need to be changed to allow for 64-bit time_t values (with attendant interoperability considerations). --ado

1 0

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

If someone with a 64-bit machine could check out the attached (and if everyone could check out the logic), I'd love it. --ado SCCS/s.localtime.c: 7.45 vs. 7.46 *** 7.45/localtime.c Wed Oct 18 16:36:18 1995 --- 7.46/localtime.c Wed Oct 18 16:36:20 1995 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.45"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.46"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1173,1178 **** --- 1173,1189 ---- if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; y = EPOCH_YEAR; + #define CYCLE_DAYS 1022679L /* Any consecutive CYCLE_DAYS days... */ + #define CYCLE_YEARS 2800L /* make up exactly CYCLE_YEARS years. */ + if (days >= CYCLE_DAYS || days <= -CYCLE_DAYS) { + register int cycles; + + cycles = (days >= 0) ? + (days / CYCLE_DAYS) : + (-1 - (-1 - days) / CYCLE_DAYS); + days -= cycles * CYCLE_DAYS; + y += cycles * CYCLE_YEARS; + } if (days >= 0) for ( ; ; ) { yleap = isleap(y);

2 1

Re: timezone stuff on 64 bit machines
by ado Oct. 18, 1995

Oct. 18, 1995

> Is there a chance of getting a 64 bit fix for the timezone stuff? The fix is to use the fact that--at least for now--the calendar operates on a grand 2800-year cycle: any set of 2800 consecutive years contains exactly 1,022,679 days. A bit of modular arithmetic will get us where we want to be. --ado

2 1

timezone stuff on 64 bit machines
by Erik Troan Oct. 18, 1995

Oct. 18, 1995

I'm trying to use the timezone stuff you maintain on a 64-bit Alpha running Linux. It builds fine, but the timezone compiler has some trouble (it runs forever). I tracked the problem down to this code from timesub(): if (days >= 0) for ( ; ; ) { yleap = isleap(y); if (days < (long) year_lengths[yleap]) break; ++y; days = days - (long) year_lengths[yleap]; } else do { --y; yleap = isleap(y); days = days + (long) year_lengths[yleap]; } while (days < 0); This works fine when the number of years you can represent is small, as it is on a 32 bit machine. On a 64-bit machine however, you have some 4 billion more years to worry about. That means this loop has to repeat well over 4 billion times, and that takes 1 while :-) Any ideas on how to fix this? Erik ------------------------------------------------------------------------------- "Eggheads unite! You have nothing to lose but your yolks" - Adlai Stevenson Erik Troan = http://sunsite.unc.edu/ewt/ = ewt(a)sunsite.unc.edu

3 4

tzcode95e.tar.gz
by ado Oct. 13, 1995

Oct. 13, 1995

The mktime change to scan from future to past when trying to find time zone offsets has been incorporated into tzcode95e.tar.gz, available from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory. --ado

1 0

time to retire SystemV?
by eggert＠twinsun.com Oct. 11, 1995

Oct. 11, 1995

I'm forwarding the following message originally posted to comp.os.linux.admin. Given the potential for confusion, perhaps it's time to comment-out the SystemV zones, for the same reason that US/Pacific-PET is commented out? Newsgroups: comp.os.linux.misc,comp.os.linux.admin From: davidsen(a)sixhub.tmr.com (Bill Davidsen) Subject: Who fixes broken timezones? Reply-To: davidsen(a)tmr.com (bill davidsen) Organization: TMR Associates, Schenectady NY Date: Mon, 9 Oct 1995 23:09:50 GMT Message-ID: <DG7F0G.43t(a)sixhub.tmr.com> This spring I posted a note saying the daylight savings time was broken. After about 50 people assured me it wasn't, Peter Dalgaard noted that "SystemV/EST5EDT" is broken and "US/Eastern" is not (guess most people use that). I just checked the 2.3 Slackware release and it's still wrong, so would someone tell me who maintains this so it can get fixed before it bites people again next year? Note: view the settings with zdump -v -c 2000 <filename> | grep 1995 the SystemV version thinks DST starts on the last Sunday of the month, not the first! -- TMR Associates, Inc +1 518 370-5654

1 0

Re: mktime problems when adjusting tm_isdst
by Bradley White Oct. 10, 1995

Oct. 10, 1995

I guess I would benefit from a succinct explanation of what mktime(`TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdst=1') is supposed to mean. Paul's assertion ... > Surely the result should be > `1996-12-31 23:00:00 tm_isdst=0'. ..., while perhaps true, doesn't seem patently obvious. If I took `TZ=Europe/Paris 1995-06-01 00:00:00 tm_isdst=1', for example, and added six months, I think I would prefer to see a `1996-01-01 00:00:00 tm_isdst=0' mktime() result. In any case, a clear definition will tell us what to do with the code. Bradley

2 1

Re: mktime problems when adjusting tm_isdst
by ado Oct. 10, 1995

Oct. 10, 1995

We could run through the transition times from future to past (rather than from past to future as is done now); this doesn't solve the deep problem, but does get the "TZ=Europe/Paris 1996-01-01 00:00:00 tm_isdt=1" case right. It does have the advantage of being a fairly minimal change to the code. --ado *************** *** 1458,1467 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = 0; samei < sp->typecnt; ++samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = 0; otheri < sp->typecnt; ++otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1458,1467 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff -

2 1

Re: mktime problems when adjusting tm_isdst
by Chris Torek Oct. 10, 1995

Oct. 10, 1995

>... and I worry that it might break some applications that assume >that tm_isdst==1 means ``use normal DST''. I think there may also be applications that use tm_isdst as a subscript into a two-element array. Breaking these could be considered doing them a favor, :-) Chris

1 0

mktime problems when adjusting tm_isdst
by Paul Eggert Oct. 10, 1995

Oct. 10, 1995

With TZ=Europe/Paris, when I invoke mktime on the equivalent of `1996-01-01 00:00:00 tm_isdst=1', it returns the equivalent of `1995-12-31 23:09:21 tm_isdst=0'. Surely the result should be `1996-12-31 23:00:00 tm_isdst=0'. (This is tzcode95d compiled on Solaris 2.4.) The problem seems to be that mktime discovers that the requested time exists only in standard time, so it corrects it by subtracting the first known GMT offset using DST and adding the first known GMT offset not using DST. But Europe/Paris currently uses different DST rules (and a different GMT offset) than it did in 1916 and 1911, respectively. The obvious workaround for this case is to change time1() so that it uses the nearest DST and non-DST transitions just before the requested time, instead of the first possible DST and non-DST transitions. But this breaks down in other cases. For example, in Europe/Paris at 1940-06-15 00:00:00, the GMT offset is 2 hours, tm_isdst=1 and there's a 1-hour DST offset, but at the most recent non-DST period the GMT offset is 0 hours, so mktime will wrongly adjust the time by 2 hours. There's a deeper problem here. How should mktime adjust for DST in a locale that has multiple DST offsets? For example, suppose TZ=America/St_Johns and I invoke mktime on the equivalent of `1989-01-01 00:00:00 tm_isdst=1'. Newfoundland used a 2-hour DST offset in summer 1988 and a 1-hour DST offset in summer 1989, so should the requested time be adjusted by 1 hour or by 2? One possible way to address the deeper problem, suggested by Mark Brader, is to represent different DST offsets by using different tm_isdst values. For example, instead of simply being 1 when some sort of DST is in effect, tm_isdst could be the DST offset, in seconds modulo INT_MAX+1. That way, mktime can tell which DST offset was used to derive its input time, and it can adjust the time correctly when it finds that a different DST offset is needed. I think this change would make it easy to fix the Europe/Paris bug mentioned above. But it's a nontrivial change to the tz code and I worry that it might break some applications that assume that tm_isdst==1 means ``use normal DST''. Here's a test program to reproduce the bug describe above. Run it with TZ set to Europe/Paris as built from tzdata95i.tar.gz, and give it the arguments `1996-01-01 00:00:00 1'. #include <stdio.h> #include <time.h> #define TM_YEAR_BASE 1900 static void print_tm (tp) struct tm *tp; { printf ("%04d-%02d-%02d %02d:%02d:%02d yday %03d wday %d isdst %d", tp->tm_year + TM_YEAR_BASE, tp->tm_mon + 1, tp->tm_mday, tp->tm_hour, tp->tm_min, tp->tm_sec, tp->tm_yday, tp->tm_wday, tp->tm_isdst); } int main (argc, argv) int argc; char **argv; { time_t t; struct tm tm; char trailer; if (argc == 4 && (sscanf (argv[1], "%d-%d-%d%c", &tm.tm_year, &tm.tm_mon, &tm.tm_mday, &trailer) == 3) && (sscanf (argv[2], "%d:%d:%d%c", &tm.tm_hour, &tm.tm_min, &tm.tm_sec, &trailer) == 3) && (sscanf (argv[3], "%d%c", &tm.tm_isdst, &trailer) == 1)) { tm.tm_year -= TM_YEAR_BASE; tm.tm_mon--; t = mktime (&tm); printf ("mktime returns %ld == ", (long) t); print_tm (&tm); printf ("\n"); } else printf ("Usage:\t%s YYYY-MM-DD HH:MM:SS ISDST # Test given time.\n", argv[0]); return 0; }

1 0

Re: When should Canada/Central return to Standard Time?
by ado Sept. 26, 1995

Sept. 26, 1995

> Given Shanks's data, I'd guess that the Sun customer's ``one week too > early'' was just a approximation, and the true error is one month too > early. This is consistent with the rest of Canada. Here is a > proposed patch. The suggested has been incorporated into tzdata95i.tar.gz, available by anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (165.112.73.1). --ado

1 0

Re: When should Canada/Central return to Standard Time?
by Paul Eggert Sept. 26, 1995

Sept. 26, 1995

I consulted Shanks and found that I transcribed his data for Winnipeg incorrectly, not only for this year, but also for 1937, 1948, 1950, 1963, and all years from 1966 on. Sorry about that -- I must have forgotten to proofread Winnipeg originally. (At least I didn't misspell its name as ``Winnepeg''....) Given Shanks's data, I'd guess that the Sun customer's ``one week too early'' was just a approximation, and the true error is one month too early. This is consistent with the rest of Canada. Here is a proposed patch. =================================================================== RCS file: RCS/northamerica,v retrieving revision 1995.8 retrieving revision 1995.8.1.1 diff -c -r1995.8 -r1995.8.1.1 *** northamerica 1995/09/21 15:26:26 1995.8 --- northamerica 1995/09/26 10:36:47 1995.8.1.1 *************** *** 464,484 **** Rule Winn 1918 only - Apr 14 2:00 1:00 D Rule Winn 1918 only - Oct 31 2:00 0 S Rule Winn 1937 only - May 16 2:00 1:00 D ! Rule Winn 1937 only - Sep 23 2:00 0 S Rule Winn 1942 only - Feb 9 2:00 1:00 D Rule Winn 1945 only - Sep lastSun 2:00 0 S Rule Winn 1946 only - May 12 2:00 1:00 D Rule Winn 1946 only - Oct 13 2:00 0 S Rule Winn 1947 1949 - Apr lastSun 2:00 1:00 D ! Rule Winn 1947 1958 - Sep lastSun 2:00 0 S ! Rule Winn 1948 only - May 1 2:00 1:00 D ! Rule Winn 1948 1960 - Apr lastSun 2:00 1:00 D Rule Winn 1959 only - Oct lastSun 2:00 0 S Rule Winn 1960 only - Sep lastSun 2:00 0 S Rule Winn 1963 only - Apr lastSun 2:00 1:00 D ! Rule Winn 1963 only - Sep lastSun 2:00 0 S Rule Winn 1966 1986 - Apr lastSun 2:00 1:00 D ! Rule Winn 1966 max - Sep lastSun 2:00 0 S Rule Winn 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16 --- 464,486 ---- Rule Winn 1918 only - Apr 14 2:00 1:00 D Rule Winn 1918 only - Oct 31 2:00 0 S Rule Winn 1937 only - May 16 2:00 1:00 D ! Rule Winn 1937 only - Sep 26 2:00 0 S Rule Winn 1942 only - Feb 9 2:00 1:00 D Rule Winn 1945 only - Sep lastSun 2:00 0 S Rule Winn 1946 only - May 12 2:00 1:00 D Rule Winn 1946 only - Oct 13 2:00 0 S Rule Winn 1947 1949 - Apr lastSun 2:00 1:00 D ! Rule Winn 1947 1949 - Sep lastSun 2:00 0 S ! Rule Winn 1950 only - May 1 2:00 1:00 D ! Rule Winn 1950 only - Sep 30 2:00 0 S ! Rule Winn 1951 1960 - Apr lastSun 2:00 1:00 D ! Rule Winn 1951 1958 - Sep lastSun 2:00 0 S Rule Winn 1959 only - Oct lastSun 2:00 0 S Rule Winn 1960 only - Sep lastSun 2:00 0 S Rule Winn 1963 only - Apr lastSun 2:00 1:00 D ! Rule Winn 1963 only - Sep 22 2:00 0 S Rule Winn 1966 1986 - Apr lastSun 2:00 1:00 D ! Rule Winn 1966 max - Oct lastSun 2:00 0 S Rule Winn 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16

1 0

Is the current Canada/Central zoneinfo correct?
by unknown＠example.com Sept. 25, 1995

Sept. 25, 1995

I am the guy who maintains the zoneinfo stuff in Solaris 2 and one of our customers just submitted a bug against the current Canada/Central (aka America/Winnepeg) entry complaining that it switches back to Standard Time one week too early. The current entry for Canada/Central says that it should switch on the last Sunday in September, which would have been yesterday, the 24th. Who is right? Our customer or the current zoneinfo source? alan perry

2 1

Re: Is the current Canada/Central zoneinfo correct?
by ado Sept. 25, 1995

Sept. 25, 1995

I called Tourism Winnipeg, (800) 665-0204, at 8:55 p.m. GMT on 9/25/95 (4:55 p.m. in Washington, DC; US Eastern Daylight Time, the same as New York). The answering party said it was 3:55 in Winnipeg; Winnipeg being Central, this one-hour difference would indicate they're also still on Daylight Time. The current "northamerica" file yields a two-hour difference, and shows Winnipeg back on Standard Time (indicated by the "CST" below): Script started on Mon Sep 25 17:19:30 1995 elsie$ ./zdump GMT America/New_York America/Winnipeg GMT Mon Sep 25 21:19:41 1995 GMT America/New_York Mon Sep 25 17:19:41 1995 EDT America/Winnipeg Mon Sep 25 15:19:41 1995 CST elsie$ exit script done on Mon Sep 25 17:19:45 1995 So it does look as if something is amiss. Whether it's the rule or the answering party, what the right rule is, and what area the right rule applies in deponent sayeth not. --ado

1 0

tzdata95h.tar.gz
by ado Sept. 21, 1995

Sept. 21, 1995

tzdata95h.tar.gz, incorporating the latest changes from Paul Eggert, is now available from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory. --ado

1 0