- tz - lists.iana.org

Re: proposed changes to tz `africa' file for SAST, WAT, Namibia, etc.
by Mark R V Murray Oct. 7, 1997

Oct. 7, 1997

Paul Eggert wrote: > Mark R V Murray <markm(a)iafrica.com>'s recent letter to the tz list led > to an extended offline discussion. It appears that many of the time > zone abbreviations used in the `africa' file don't reflect actual > practice. So the patch at the end of this messages proposes the > following changes to the time zone abbreviations used in the `africa' > file: [snip] This all looks great! Thanks a lot! M -- Mark Murray Senior Network Engineer, UUNET Internet Africa Join the anti-SPAM movement: http://www.cauce.org

1 0

tzdata1997i.tar.gz
by ado Oct. 7, 1997

Oct. 7, 1997

The file ftp://elsie.nci.nih.gov/pub/tzdata1997i.tar.gz is now available, incorporating the changes to Africa recentely circulated on the time zone mailing list by Paul Eggert. --ado

1 0

proposed changes to tz `africa' file for SAST, WAT, Namibia, etc.
by Paul Eggert Oct. 6, 1997

Oct. 6, 1997

Mark R V Murray <markm(a)iafrica.com>'s recent letter to the tz list led to an extended offline discussion. It appears that many of the time zone abbreviations used in the `africa' file don't reflect actual practice. So the patch at the end of this messages proposes the following changes to the time zone abbreviations used in the `africa' file: UTC abbreviation offset old new -1:00 AAT WAT (This offset hasn't been used since 1976.) 0:00 WAT GMT 1:00 CAT WAT 2:00 SAT SAST in South Africa, Lesotho, and Swaziland (and in Namibia before independence); CAT elsewhere 3:00 EAT EAT (i.e. no change) Having `WAT' stand for both -1:00 and 1:00 is a tricky, but it's not the first instance of ambiguity in the tz database, and I can't think of a better way to solve the problem. Murray's letter also prompted me to go through the 1995 edition of Shanks looking for changes relevant to Africa and correcting some old transcription errors, and the patch at the end of this message also includes the following proposed changes: - Change Namibia (Africa/Windhoek) from +2:00 to +1:00 as of 1994. This was also in Gwillim Law's IATA data but I somehow missed it. - Change the Egypt time zone rules to agree with Shanks, who says that Egypt still makes its transitions at 1:00 (spring) and 3:00 (fall) local time. This seems more plausible than the IATA's 0:00. - Use ADMT to abbreviate Ethiopian time between 1890 and 1936. Shanks says Ethiopia had six narrowly-spaced time zones between 1870 and 1890, and from 1890 to 1936 Ethiopia was at 38E50. The only town in Shanks's database with this longitude that had time at 38E50 in 1870 is Adis Dera, so I'm guessing that it's Adis Dera Mean Time (ADMT). - Fix four data transcription errors, as follows: Africa/Conakry was at -1:00 (not 1:00) between 1934 and 1960. Similarly, Africa/Bissau was at -1:00 (not 1:00) between 1911 and 1975, and Africa/Niamey was at -1:00 (not 1:00) between 1912 and 1934. Sierra Leone (Africa/Freetown) observed a 40-minute DST offset between 1935 and 1942, not a 1-hour DST offset. - I had no evidence for my ``corrections'' to Shanks for British East Africa in 1940-1957, so I removed them. To help avoid the confusion about +2:30 versus +2:45 I invented the abbreviation BEAUT for the latter. - Correct Shanks's evident transcription error for Atlantic/St_Helena between 1890 and 1951. - Change the abbreviation for Sudan (Africa/Khartoum) from EET to CAT. It seems marginally plausible that the African countries on the Mediterranean coast would use European time zone abbreviations; it doesn't seem plausible that countries further south would. =================================================================== RCS file: RCS/africa,v retrieving revision 1997.8 retrieving revision 1997.8.1.1 diff -c -r1997.8 -r1997.8.1.1 *** africa 1997/09/04 20:54:16 1997.8 --- africa 1997/10/06 07:08:41 1997.8.1.1 *************** *** 4,14 **** # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (1996-11-22): # # A good source for time zone historical data outside the U.S. is ! # Thomas G. Shanks, The International Atlas (3rd edition), ! # San Diego: ACS Publications, Inc. (1991). # # Gwillim Law <LAW(a)encmail.encompass.com> writes that a good source # for recent time zone data is the International Air Transport --- 4,14 ---- # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (1997-10-05): # # A good source for time zone historical data outside the U.S. is ! # Thomas G. Shanks, The International Atlas (4th edition), ! # San Diego: ACS Publications, Inc. (1995). # # Gwillim Law <LAW(a)encmail.encompass.com> writes that a good source # for recent time zone data is the International Air Transport *************** *** 27,42 **** # Derek Howse, Greenwich time and the discovery of the longitude, # Oxford University Press (1980). # ! # For Africa I invented the following time zone abbreviations. ! # LMT Local Mean Time ! # -1:00 AAT Atlantic Africa Time (no longer used) ! # 0:00 WAT West Africa Time ! # 1:00 CAT Central Africa Time ! # 2:00 SAT South Africa Time # 3:00 EAT East Africa Time ! # The final `T' is replaced by `ST' for summer time, e.g. `SAST'. ! # BEAT is British East Africa Time, which was 2:30 before 1948 and 2:45 after. ! # Algeria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S --- 27,66 ---- # Derek Howse, Greenwich time and the discovery of the longitude, # Oxford University Press (1980). # ! # Previous editions of this database used WAT, CAT, SAT, and EAT ! # for +0:00 through +3:00, respectively, ! # but Mark R V Murray <markm(a)iafrica.com> reports that ! # `SAST' is the official abbreviation for +2:00 in the country of South Africa, ! # `CAT' is commonly used for +2:00 in countries north of South Africa, and ! # `WAT' is probably the best name for +1:00, as the common phrase for ! # the area that includes Nigeria is ``West Africa''. ! # He has heard of ``Western Sahara Time'' for +0:00 but can find no reference. ! # ! # To make things confusing, `WAT' seems to have been used for -1:00 long ago; ! # I'd guess that this was because people needed _some_ name for -1:00, ! # and at the time, far west Africa was the only major land area in -1:00. ! # This usage is now obsolete, as the last use of -1:00 on the African ! # mainland seems to have been 1976 in Western Sahara. ! # ! # To summarize, the following abbreviations seem to have some currency: ! # -1:00 WAT West Africa Time (no longer used) ! # 0:00 GMT Greenwich Mean Time ! # 2:00 CAT Central Africa Time ! # 2:00 SAST South Africa Standard Time ! # and Murray suggests the following abbreviation: ! # 1:00 WAT West Africa Time ! # I realize that this leads to `WAT' being used for both -1:00 and 1:00 ! # for times before 1976, but this is the best I can think of ! # until we get more information. ! # ! # I invented the following abbreviations; corrections are welcome! ! # 2:00 WAST West Africa Summer Time ! # 2:30 BEAT British East Africa Time (no longer used) ! # 2:45 BEAUT British East Africa Unified Time (no longer used) ! # 3:00 CAST Central Africa Summer Time (no longer used) ! # 3:00 SAST South Africa Summer Time (no longer used) # 3:00 EAT East Africa Time ! # 4:00 EAST East Africa Summer Time (no longer used) # Algeria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S *************** *** 79,85 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Luanda 0:52:56 - LMT 1892 0:52:04 - LMT 1911 May 26 # Luanda Mean Time? ! 1:00 - CAT # Bassas da India # uninhabited --- 103,109 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Luanda 0:52:56 - LMT 1892 0:52:04 - LMT 1911 May 26 # Luanda Mean Time? ! 1:00 - WAT # Bassas da India # uninhabited *************** *** 88,118 **** # Whitman says they switched to 1:00 in 1946, not 1934; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Porto-Novo 0:10:28 - LMT 1912 ! 0:00 - WAT 1934 Feb 26 ! 1:00 - CAT # Botswana # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Gaborone 1:43:40 - LMT 1885 ! 2:00 - SAT 1943 Sep 19 2:00 ! 2:00 1:00 SAST 1944 Mar 19 2:00 ! 2:00 - SAT # Burkina Faso # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Ouagadougou -0:06:04 - LMT 1912 ! 0:00 - WAT # Burundi # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bujumbura 1:57:28 - LMT 1890 ! 2:00 - SAT # Cameroon # Whitman says they switched to 1:00 in 1920; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Douala 0:38:48 - LMT 1912 ! 1:00 - CAT # Cape Verde # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 112,142 ---- # Whitman says they switched to 1:00 in 1946, not 1934; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Porto-Novo 0:10:28 - LMT 1912 ! 0:00 - GMT 1934 Feb 26 ! 1:00 - WAT # Botswana # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Gaborone 1:43:40 - LMT 1885 ! 2:00 - CAT 1943 Sep 19 2:00 ! 2:00 1:00 CAST 1944 Mar 19 2:00 ! 2:00 - CAT # Burkina Faso # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Ouagadougou -0:06:04 - LMT 1912 ! 0:00 - GMT # Burundi # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bujumbura 1:57:28 - LMT 1890 ! 2:00 - CAT # Cameroon # Whitman says they switched to 1:00 in 1920; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Douala 0:38:48 - LMT 1912 ! 1:00 - WAT # Cape Verde # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 125,138 **** # Central African Republic # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bangui 1:14:20 - LMT 1912 ! 1:00 - CAT # Chad # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Ndjamena 1:00:12 - LMT 1912 ! 1:00 - CAT 1979 Oct 14 ! 1:00 1:00 CAST 1980 Mar 8 ! 1:00 - CAT # Comoros # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 149,162 ---- # Central African Republic # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bangui 1:14:20 - LMT 1912 ! 1:00 - WAT # Chad # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Ndjamena 1:00:12 - LMT 1912 ! 1:00 - WAT 1979 Oct 14 ! 1:00 1:00 WAST 1980 Mar 8 ! 1:00 - WAT # Comoros # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 142,160 **** # Democratic Republic of Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Kinshasa 1:01:12 - LMT 1897 Nov 9 ! 1:00 - CAT Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 ! 2:00 - SAT # Republic of the Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Brazzaville 1:01:08 - LMT 1912 ! 1:00 - CAT # Cote D'Ivoire # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Abidjan -0:16:08 - LMT 1912 ! 0:00 - WAT # Djibouti # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 166,184 ---- # Democratic Republic of Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Kinshasa 1:01:12 - LMT 1897 Nov 9 ! 1:00 - WAT Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 ! 2:00 - CAT # Republic of the Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Brazzaville 1:01:08 - LMT 1912 ! 1:00 - WAT # Cote D'Ivoire # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Abidjan -0:16:08 - LMT 1912 ! 0:00 - GMT # Djibouti # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 165,182 **** # Egypt - # From Bob Devine (1988-01-28): - # Egypt: DST from first day of May to first of October (ending may - # also be on Sept 30th not 31st -- you might want to ask one of the - # soc.* groups, you might hit someone who could ask an embassy). - # DST since 1960 except for 1981-82. - - # From U. S. Naval Observatory (1989-01-19): - # EGYPT 2 H AHEAD OF UTC - # EGYPT 3 H AHEAD OF UTC MAY 17 - SEP 30 (AFTER - # EGYPT RAMADAN) - - # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Egypt 1940 only - Jul 15 0:00 1:00 S Rule Egypt 1940 only - Oct 1 0:00 0 - --- 189,194 ---- *************** *** 191,206 **** Rule Egypt 1958 only - May 1 0:00 1:00 S Rule Egypt 1959 1981 - May 1 1:00 1:00 S Rule Egypt 1959 1965 - Sep 30 3:00 0 - ! Rule Egypt 1966 1990 - Oct 1 3:00 0 - Rule Egypt 1982 only - Jul 25 1:00 1:00 S Rule Egypt 1983 only - Jul 12 1:00 1:00 S Rule Egypt 1984 1988 - May 1 1:00 1:00 S Rule Egypt 1989 only - May 6 1:00 1:00 S ! Rule Egypt 1990 only - May 1 1:00 1:00 S ! Rule Egypt 1991 1994 - May 1 0:00 1:00 S ! Rule Egypt 1991 1994 - Oct 1 0:00 0 - ! Rule Egypt 1995 max - Apr lastFri 0:00 1:00 S ! Rule Egypt 1995 max - Sep lastFri 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Cairo 2:05:00 - LMT 1900 Oct --- 203,217 ---- Rule Egypt 1958 only - May 1 0:00 1:00 S Rule Egypt 1959 1981 - May 1 1:00 1:00 S Rule Egypt 1959 1965 - Sep 30 3:00 0 - ! Rule Egypt 1966 1994 - Oct 1 3:00 0 - Rule Egypt 1982 only - Jul 25 1:00 1:00 S Rule Egypt 1983 only - Jul 12 1:00 1:00 S Rule Egypt 1984 1988 - May 1 1:00 1:00 S Rule Egypt 1989 only - May 6 1:00 1:00 S ! Rule Egypt 1990 1994 - May 1 1:00 1:00 S ! # IATA (after 1990) says transitions are at 0:00; go with Shanks. ! Rule Egypt 1995 max - Apr lastFri 1:00 1:00 S ! Rule Egypt 1995 max - Sep lastFri 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Cairo 2:05:00 - LMT 1900 Oct *************** *** 209,228 **** # Equatorial Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Malabo 0:35:08 - LMT 1912 ! 0:00 - WAT 1963 Dec 15 ! 1:00 - CAT # Eritrea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Asmera 2:35:32 - LMT 1870 2:35:32 - AMT 1890 # Asmera Mean Time ! 2:35:20 - AAMT 1936 May 5 # Addis Ababa MT? 3:00 - EAT # Ethiopia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Addis_Ababa 2:34:48 - LMT 1870 ! 2:35:20 - AAMT 1936 May 5 # Addis Ababa MT? 3:00 - EAT # Europa Island --- 220,243 ---- # Equatorial Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Malabo 0:35:08 - LMT 1912 ! 0:00 - GMT 1963 Dec 15 ! 1:00 - WAT # Eritrea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Asmera 2:35:32 - LMT 1870 2:35:32 - AMT 1890 # Asmera Mean Time ! 2:35:20 - ADMT 1936 May 5 # Adis Dera MT 3:00 - EAT # Ethiopia + # From Paul Eggert (1997-10-05): + # Shanks writes that Ethiopia had six narrowly-spaced time zones between + # 1870 and 1890, and that they merged to 38E50 (2:35:20) in 1890. + # We'll guess that 38E50 is for Adis Dera. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Addis_Ababa 2:34:48 - LMT 1870 ! 2:35:20 - ADMT 1936 May 5 # Adis Dera MT 3:00 - EAT # Europa Island *************** *** 231,253 **** # Gabon # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Libreville 0:37:48 - LMT 1912 ! 1:00 - CAT # Gambia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Banjul -1:06:36 - LMT 1912 -1:06:36 - BMT 1935 # Banjul Mean Time ! -1:00 - AAT 1964 ! 0:00 - WAT # Ghana - # From Paul Eggert <eggert(a)twinsun.com> (1996-09-03): - # WATST is my invention for ``West Africa one-Third Summer Time''. - # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman says DST was observed from 1931 to ``the present''; go with Shanks. ! Rule Ghana 1936 1942 - Sep 1 0:00 0:20 WATST ! Rule Ghana 1936 1942 - Dec 31 0:00 0 WAT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s --- 246,265 ---- # Gabon # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Libreville 0:37:48 - LMT 1912 ! 1:00 - WAT # Gambia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Banjul -1:06:36 - LMT 1912 -1:06:36 - BMT 1935 # Banjul Mean Time ! -1:00 - WAT 1964 ! 0:00 - GMT # Ghana # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman says DST was observed from 1931 to ``the present''; go with Shanks. ! Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST ! Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s *************** *** 258,292 **** # Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Conakry -0:54:52 - LMT 1912 ! 0:00 - WAT 1934 Feb 26 ! 1:00 - CAT 1960 ! 0:00 - WAT # Guinea-Bissau # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bissau -1:02:20 - LMT 1911 May 26 ! 1:00 - CAT 1975 ! 0:00 - WAT # Juan de Nova # uninhabited # Kenya - # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): - # Shanks says the transition to 2:45 was in 1940, but it must have been 1948. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Nairobi 2:27:16 - LMT 1928 Jul 3:00 - EAT 1930 ! 2:30 - BEAT 1948 ! 2:45 - BEAT 1960 3:00 - EAT # Lesotho # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Maseru 1:50:00 - LMT 1903 Mar ! 2:00 - SAT 1943 Sep 19 2:00 2:00 1:00 SAST 1944 Mar 19 2:00 ! 2:00 - SAT # Liberia # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): --- 270,302 ---- # Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Conakry -0:54:52 - LMT 1912 ! 0:00 - GMT 1934 Feb 26 ! -1:00 - WAT 1960 ! 0:00 - GMT # Guinea-Bissau # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bissau -1:02:20 - LMT 1911 May 26 ! -1:00 - WAT 1975 ! 0:00 - GMT # Juan de Nova # uninhabited # Kenya # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Nairobi 2:27:16 - LMT 1928 Jul 3:00 - EAT 1930 ! 2:30 - BEAT 1940 ! 2:45 - BEAUT 1960 3:00 - EAT # Lesotho # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Maseru 1:50:00 - LMT 1903 Mar ! 2:00 - SAST 1943 Sep 19 2:00 2:00 1:00 SAST 1944 Mar 19 2:00 ! 2:00 - SAST # Liberia # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): *************** *** 297,321 **** # For Liberia before 1972, Shanks reports -0:44, whereas Howse and Whitman # each report -0:44:30; go with the more precise figure. # ! # From Shanks (1991), as corrected by Whitman: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Monrovia -0:43:08 - LMT 1882 -0:43:08 - MMT 1919 Mar # Monrovia Mean Time -0:44:30 - LRT 1972 May # Liberia Time ! 0:00 - WAT ############################################################################### # Libya - # From Bob Devine (January 28 1988): - # Libya: Since 1982 April 1st to September 30th (?) - - # From U. S. Naval Observatory (1989-01-19): - # LIBYAN ARAB 1 H AHEAD OF UTC JAMAHIRIYA/LIBYA - # LIBYAN ARAB 2 H AHEAD OF UTC APR 1 - SEP 30 JAMAHIRIYA/LIBYA - - # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Libya 1951 only - Oct 14 2:00 1:00 S Rule Libya 1952 only - Jan 1 0:00 0 - --- 307,323 ---- # For Liberia before 1972, Shanks reports -0:44, whereas Howse and Whitman # each report -0:44:30; go with the more precise figure. # ! # From Shanks, as corrected by Whitman: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Monrovia -0:43:08 - LMT 1882 -0:43:08 - MMT 1919 Mar # Monrovia Mean Time -0:44:30 - LRT 1972 May # Liberia Time ! 0:00 - GMT ############################################################################### # Libya # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Libya 1951 only - Oct 14 2:00 1:00 S Rule Libya 1952 only - Jan 1 0:00 0 - *************** *** 353,376 **** # Malawi # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Blantyre 2:20:00 - LMT 1903 Mar ! 2:00 - SAT # Mali # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bamako -0:32:00 - LMT 1912 ! 0:00 - WAT 1934 Feb 26 ! -1:00 - AAT 1960 Jun 20 ! 0:00 - WAT # no longer different from Bamako, but too famous to omit Zone Africa/Timbuktu -0:12:04 - LMT 1912 ! 0:00 - WAT # Mauritania # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Nouakchott -1:03:48 - LMT 1912 ! 0:00 - WAT 1934 Feb 26 ! -1:00 - AAT 1960 Jun 20 ! 0:00 - WAT # Mauritius # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 355,378 ---- # Malawi # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Blantyre 2:20:00 - LMT 1903 Mar ! 2:00 - CAT # Mali # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Bamako -0:32:00 - LMT 1912 ! 0:00 - GMT 1934 Feb 26 ! -1:00 - WAT 1960 Jun 20 ! 0:00 - GMT # no longer different from Bamako, but too famous to omit Zone Africa/Timbuktu -0:12:04 - LMT 1912 ! 0:00 - GMT # Mauritania # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Nouakchott -1:03:48 - LMT 1912 ! 0:00 - GMT 1934 Feb 26 ! -1:00 - WAT 1960 Nov 28 ! 0:00 - GMT # Mauritius # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 385,390 **** --- 387,393 ---- 3:00 - EAT # Morocco + # See the `europe' file for Spanish Morocco (Africa/Ceuta). # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Morocco 1939 only - Sep 12 0:00 1:00 S Rule Morocco 1939 only - Nov 19 0:00 0 - *************** *** 408,443 **** 0:00 - WET # Western Sahara Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan ! -1:00 - AAT 1976 Apr 14 0:00 - WET # Mozambique # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Maputo 2:10:20 - LMT 1903 Mar ! 2:00 - SAT # Namibia # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Namibia 1994 max - Sep Sun>=1 2:00 1:00 S Rule Namibia 1995 max - Apr Sun>=1 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - SWAT 1903 Mar # SW Africa Time ! 2:00 - SAT 1942 Sep 20 2:00 2:00 1:00 SAST 1943 Mar 21 2:00 ! 2:00 Namibia SA%sT # Niger # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Africa/Niamey 0:08:28 - LMT 1912 ! 1:00 - CAT 1934 Feb 26 ! 0:00 - WAT 1960 ! 1:00 - CAT # Nigeria # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lagos 0:13:36 - LMT 1919 Sep ! 1:00 - CAT # Reunion # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 411,450 ---- 0:00 - WET # Western Sahara Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan ! -1:00 - WAT 1976 Apr 14 0:00 - WET # Mozambique # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Maputo 2:10:20 - LMT 1903 Mar ! 2:00 - CAT # Namibia + # Shanks says DST transitions are at 0:00; go with IATA. + # The 1994-04-03 transition is from Shanks. # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Namibia 1994 max - Sep Sun>=1 2:00 1:00 S Rule Namibia 1995 max - Apr Sun>=1 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - SWAT 1903 Mar # SW Africa Time ! 2:00 - SAST 1942 Sep 20 2:00 2:00 1:00 SAST 1943 Mar 21 2:00 ! 2:00 - SAST 1990 Mar 21 # independence ! 2:00 - CAT 1994 Apr 3 ! 1:00 Namibia WA%sT # Niger # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Africa/Niamey 0:08:28 - LMT 1912 ! -1:00 - WAT 1934 Feb 26 ! 0:00 - GMT 1960 ! 1:00 - WAT # Nigeria # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lagos 0:13:36 - LMT 1919 Sep ! 1:00 - WAT # Reunion # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 447,458 **** # Rwanda # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Kigali 2:00:16 - LMT 1935 Jun ! 2:00 - SAT # St Helena # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/St_Helena -0:22:48 - LMT 1890 # Jamestown ! -0:06 - SHT 1951 # St Helena Time (?) 0:00 - GMT # The other parts of the St Helena territory are similar: # Tristan da Cunha: on GMT, say Whitman and the CIA --- 454,468 ---- # Rwanda # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Kigali 2:00:16 - LMT 1935 Jun ! 2:00 - CAT # St Helena + # From Paul Eggert (1997-10-05): + # Shanks says St Helena was 1W26 (-0:05:44) from 1890 to 1951, + # but this is most likely a typo for 5W42, the longitude of Jamestown. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/St_Helena -0:22:48 - LMT 1890 # Jamestown ! -0:22:48 - JMT 1951 # Jamestown Mean Time 0:00 - GMT # The other parts of the St Helena territory are similar: # Tristan da Cunha: on GMT, say Whitman and the CIA *************** *** 464,476 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Sao_Tome 0:26:56 - LMT 1884 -0:36:32 - LMT 1912 # Lisbon Mean Time ! 0:00 - WAT # Senegal # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Dakar -1:09:44 - LMT 1912 ! -1:00 - AAT 1941 Jun ! 0:00 - WAT # Seychelles # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 474,486 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Sao_Tome 0:26:56 - LMT 1884 -0:36:32 - LMT 1912 # Lisbon Mean Time ! 0:00 - GMT # Senegal # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Dakar -1:09:44 - LMT 1912 ! -1:00 - WAT 1941 Jun ! 0:00 - GMT # Seychelles # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 480,513 **** # Sierra Leone # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman gives Mar 31 - Aug 31 for 1931 on; go with Shanks. ! Rule SL 1935 1942 - Jun 1 0:00 1:00 S ! Rule SL 1935 1942 - Oct 1 0:00 0 - ! Rule SL 1957 1962 - Jun 1 0:00 1:00 S ! Rule SL 1957 1962 - Sep 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jun # Freetown Mean Time ! -1:00 SL AA%sT 1957 ! 0:00 SL WA%sT # Somalia - # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): - # Shanks omits the 1948 transition to 2:45; this is probably a typo. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Mogadishu 3:01:28 - LMT 1893 Nov 3:00 - EAT 1931 ! 2:30 - BEAT 1948 ! 2:45 - BEAT 1957 # not in Shanks 3:00 - EAT # South Africa # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule SA 1942 1943 - Sep Sun>=15 2:00 1:00 S Rule SA 1943 1944 - Mar Sun>=15 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 ! 1:30 - SAT 1903 Mar ! 2:00 SA SA%sT # Marion and Prince Edward Is # weather station since 1947 # no information --- 490,523 ---- # Sierra Leone # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman gives Mar 31 - Aug 31 for 1931 on; go with Shanks. ! Rule SL 1935 1942 - Jun 1 0:00 0:40 SLST ! Rule SL 1935 1942 - Oct 1 0:00 0 WAT ! Rule SL 1957 1962 - Jun 1 0:00 1:00 SLST ! Rule SL 1957 1962 - Sep 1 0:00 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jun # Freetown Mean Time ! -1:00 SL %s 1957 ! 0:00 SL %s # Somalia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Mogadishu 3:01:28 - LMT 1893 Nov 3:00 - EAT 1931 ! 2:30 - BEAT 1957 3:00 - EAT # South Africa # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule SA 1942 1943 - Sep Sun>=15 2:00 1:00 - Rule SA 1943 1944 - Mar Sun>=15 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 ! 1:30 - SAST 1903 Mar ! 2:00 SA SAST ! # Shanks erroneously claims that most of South Africa switched to 1:00 ! # on 1994-04-03 at 00:00. ! # # Marion and Prince Edward Is # weather station since 1947 # no information *************** *** 524,547 **** Rule Sudan 1972 1985 - Apr lastSun 0:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Khartoum 2:10:08 - LMT 1931 ! 2:00 Sudan EE%sT # Swaziland # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Mbabane 2:04:24 - LMT 1903 Mar ! 2:00 - SAT # Tanzania # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Dar_es_Salaam 2:37:08 - LMT 1931 3:00 - EAT 1948 ! 2:45 - BEAT 1961 3:00 - EAT # Togo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lome 0:04:52 - LMT 1893 ! 0:00 - WAT # Tromelin # uninhabited --- 534,557 ---- Rule Sudan 1972 1985 - Apr lastSun 0:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Khartoum 2:10:08 - LMT 1931 ! 2:00 Sudan CA%sT # Swaziland # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Mbabane 2:04:24 - LMT 1903 Mar ! 2:00 - SAST # Tanzania # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Dar_es_Salaam 2:37:08 - LMT 1931 3:00 - EAT 1948 ! 2:45 - BEAUT 1961 3:00 - EAT # Togo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lome 0:04:52 - LMT 1893 ! 0:00 - GMT # Tromelin # uninhabited *************** *** 581,595 **** Zone Africa/Kampala 2:09:40 - LMT 1928 Jul 3:00 - EAT 1930 2:30 - BEAT 1948 ! 2:45 - BEAT 1957 3:00 - EAT # Zambia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lusaka 1:53:08 - LMT 1903 Mar ! 2:00 - SAT # Zimbabwe # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Harare 2:04:12 - LMT 1903 Mar ! 2:00 - SAT --- 591,605 ---- Zone Africa/Kampala 2:09:40 - LMT 1928 Jul 3:00 - EAT 1930 2:30 - BEAT 1948 ! 2:45 - BEAUT 1957 3:00 - EAT # Zambia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lusaka 1:53:08 - LMT 1903 Mar ! 2:00 - CAT # Zimbabwe # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Harare 2:04:12 - LMT 1903 Mar ! 2:00 - CAT

1 0

net TZ access
by ncm＠cantrip.org Oct. 1, 1997

Oct. 1, 1997

From: Paul Eggert <eggert(a)twinsun.com>: > Date: Mon, 29 Sep 1997 20:25:55 -0700 (PDT) > From: ncm(a)cantrip.org (Nathan Myers) > > Many (most?) countries make a practice of announcing changes well in > advance, and the overwhelming majority of time zone queries will > concern times in those countries. > > Yes, but there's no way to know which countries those are in advance. > If you had asked me two years ago what the expiry time for Sri Lanka > should be, I'd have suggested that it would be a very long time, as > Sri Lanka hadn't futzed with their clocks at all since 1945. But when > their energy crisis hit critical mass last year, boom! The clocks got > changed. We're not obliged to predict; some governments do it for us. (Even the British Admiralty used to give a couple of months' warning.) If we throw away that information, efficiency suffers accordingly. > And surely you're not proposing a database with 0.5-day expiries for > poorer countries' time zone rules, and 12-day expiries for richer > countries', on the theory that the richer countries need the > efficiency more! Please, I said not one word about rich countries or poor countries. (A poor country, if anyone, has greater absolute need for efficiency.) > Hence, an expiry period of a fraction of the conventional period > for such a country (e.g. a month) could radically reduce the TCP > traffic for zone queries overall. > > Other solutions would reduce the IP traffic even further. For > example, the time zone server could notify the clients of changes > instead of requiring the clients to poll the server. This could be > done via multicast to cut down on packet transmission even further. A "push" policy (with attendant daemons, subcriptions, etc) would be a hard sell for something like time zone information that changes so infrequently, and has such a low perception of importance among those not subscribed to this list. > If you're stuck with a protocol in which the client must poll the > server, then probably the best you can do is have the clients poll > once after each reboot or reconnect, and also once a day at a random > time. One packet-exchange per day should be acceptable overhead for > almost all applications. If a 24-hour expiry time were the default for zone entries, the result would be about the same, with less infrastructure. Introducing an expiry period of months for EU entries, based on their stated policy, would then mainly reduce such traffic in the EU, mainly to EU members' benefit. Any country, rich or poor, can have a prior notification policy, and do the same. > Anyway, the minimum expiry period of most current TZ installations > is measured in years ... > > I still think you're being too optimistic here. Yes, most countries > have had relatively stable time zone rules during the last decade or > two. But come the next war or energy crisis, and the rules will > change again with very little notice. My remark said nothing the stability of anybody's rules. The point was that for all but a tiny handful of sites, neither the database nor the code is updated except when the OS itself is reloaded, which happens at intervals measured, on average, in years. Hence, an expiry period of a month for all entries would still give far, far more accurate results, on average, than what is in common use now. In other words, a program that took two weeks to get up-to-date on the sudden Sri Lankan time change would not be thought ill of, considering that most machines on the net *still* haven't got the change. Nathan Myers ncm(a)cantrip.org

3 2

time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

John Cowan <cowan(a)drv.cbc.com>: > I would like to point out that HTTP (both 1.0 and 1.1) > can send an "Expires:" header (in GMT) that communicates > to the client the server's notion of how long the object > is good for, exactly what we want. I propose that this > should *not* be stored in the "zoneinfo" file, because > its value should be a local decision, and "zoneinfo" > files ought to be the same everywhere (though some > will be out of date). How can files that are sometimes "out of date" be "the same everywhere"? Either they're *all* up-to-date, or some are not the same; you can't have both. Anyway, I don't see how a function looking up a time zone adjustment, and trying to decide whether to go out to the net for an update, can make that decision if the expiry time isn't stored anywhere. A site should have the option to disregard an expiry date; some sites may choose to lop off all predictions greater than seven days as too optimistic, and other sites to make the expiry date always at least seven days, to reduce traffic. This argues for an "expiration advisory" provided as part of the canonical distribution, and "expiration choice" that are by default the same, but may be different according to local preference. > I would also suggest that the next release of "zic" > incorporate a magic-number facility. To make a concrete > proposal, let us make the first four bytes equal to > "\0x14\0x1a\0x54\0x5a", or Ctrl+T, Ctrl+Z, T, Z. > This can then be incorporated into the Unix /etc/magic > file so that zoneinfo files can be described by the > "file" command. This I most emphatically agree with! There should also be a "format version" number. (Maybe it's there already.) Nathan Myers ncm(a)cantrip.org

1 0

Re: time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

John Cowan > Markus Kuhn wrote: > > Therefore, I consider anything less than 64-bit timestamps and > > nanosecond resolution in a new portable clock interface to be somewhat > > old-fashioned and ignorant about current hardware capabilities. > > And I consider a representation that is limited to the years > 1901 through 2038 rather short-sighted. It's clear that time_t, timespec, and the Java whatsit are not the final word on time/date representations. In C++, a TimeZone class could be a template that accepts any such representation, specialized for the ones actually used, and suffering limitations each imposes only when that one is used. What we need to work out is the interface for a class that computes adjustments to whatever representation is in use. This means (1) an infrastructure (protocols, conventions) to provide up-to-date zone information to programs that need it; and (2) a call interface that allows a reasonable person to write code that operates on wall-clock time with some hope of getting it right. As John Cowan pointed out, HTTP would suffice as a low-level protocol for access to zone tables across the net, but we also need to identify authoritative sources of up-to-date information; and specify caching of retrieved information with preference for the cached data up to an expiry date. This requires representing the expiry date in the cached file. Does the "zic" format permit a datestamp? Nathan Myers ncm(a)cantrip.org

3 2

time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

Paul Eggert <eggert(a)twinsun.com> wrote: > From: ncm(a)cantrip.org (Nathan Myers) > > we also need to ... specify caching of retrieved information with > preference for the cached data up to an expiry date. This requires > representing the expiry date in the cached file. > > I don't think it's realistic to insist on an expiry date for time zone > rules. In practice, these rules can change with very little notice. Many (most?) countries make a practice of announcing changes well in advance, and the overwhelming majority of time zone queries will concern times in those countries. Hence, an expiry period of fraction of the conventional period for such a country (e.g. a month) could radically reduce the TCP traffic for zone queries overall. > For example, last year the Sri Lankan government gave > less than 24 hours' notice of an emergency rule change > that moved the clocks ahead by an hour. See ``Sri > Lanka advances clock by an hour to avoid blackout'', > http://www.virtual-pc.com/lankaweb/news/items/240596-2.html > (1996-05-24). Of course some countries do not make a practice of forewarning us, and the expiry period for their cached records could be as little as 24 hours. A policy with such a short expiry period would *still* radically reduce net traffic for queries against that record, compared to an "always check the authoritative network source" policy. In practice, times for places that change with such short notice have low reliability anyway, so there seems to me little danger in giving them what might seem an unreasonably long expiration time (e.g. a week). Anyway, the minimum expiry period of most current TZ installations is measured in years, so even with the occasional blip the aggregate reliability of the times produced would still be vastly improved over the status quo. Time zone conversions are never better than a "best guess" in any case, for the reasons Paul mentions. > In general, time zone rules are ``until further notice'', > and any automated system for propagating time zone rules > will just have to take this into account. "In general", the expiry period must be assumed to be short. In specific common important cases there is good reason to make it long. The longer it is, the quicker is the response time for users, and the lower is the overall network traffic load. [Perhaps the client should be allowed to specify how long it is willing to wait for a time zone conversion, so that if the network response is too slow the cache is used regardless of its expiry date. (The daemon should update the cache anyway, if it eventually succeeds.)] Nathan Myers ncm(a)cantrip.org

2 1

RE: time zone object
by Olson, Arthur David Sept. 30, 1997

Sept. 30, 1997

As John Cowan pointed out, HTTP would suffice as a low-level protocol for access to zone tables across the net, but we also need to identify authoritative sources of up-to-date information; and specify caching of retrieved information with preference for the cached data up to an expiry date. This requires representing the expiry date in the cached file. Does the "zic" format permit a datestamp? There are bytes "reserved for future use" at the front of the file. --ado

1 0

Re: time zone object
by ncm＠cantrip.org Sept. 29, 1997

Sept. 29, 1997

John Cowan <cowan(a)drv.cbc.com> > Nathan Myers wrote: > > a "double", relative to Jan 1, 2001, ... > > would give microsecond accuracy for now, with > > precision decreasing as we pass and recede from that date; or we > > could use a 64-bit integer count of microseconds from practically > > any choice of epochs. Each representation has its advantages. > > First, note that the term "epoch" refers to the moment of time > represented as zero, not the range of expressible times. The > Unix epoch is 1997 Jan 1 00:00:00 GMT. I believe I used the term "epoch" correctly. Of course (as I said) the choice of epoch is of no interest given a fixed-precision time value. A floating-point time has greatest precision near the epoch. With a 48 bit mantissa, precision would still be better than a millisecond for dates throughout recorded history. > ... I favor the Java convention: a 64-bit signed integer > representing milliseconds, with the same epoch as Unix. That > provides sufficient resolution for normal purposes (anything > that *requires* microsecond resolution probably requires > microcode, embedded programming, or the like), and has a range > clear back to the Carboniferous Period (~300 My B.P.) Some of us do write microcode and embedded programs, and code in such environments tends make more use of time quantities than the is conventional (hence the term "real-time"). Still, the current Java convention seems tolerable for most uses. > > The second familiar problem is the crossover periods for time changes. > > Converting from microseconds-past-epoch to local time is well-defined; > > but conversion back demands accommodation to local time that doesn't > > exist (during "spring forward" gaps); and [2] local time that is > > ambiguous (before or after "fall back"). Since there isn't any really > > satisfactory solution to these, they just need to be visible (and > > unavoidable) in the interface. > > The ADO package uses the is_dst field to resolve the ambiguity. > Except during "fall back" overlaps, this field isn't required when > converting from broken-out local time to absolute time, but it is > used to resolve the ambiguity in that case. The is_dst field fails to solve the problem. The problem is that the caller of the conversion function is generally not equipped to "resolve the ambiguity", or even to determine whether there is an ambiguity to resolve. The overwhelming majority of programs do not (and probably cannot) correctly or meaningfully use the is_dst field. The conversion function itself can tell whether there might be an ambiguity, but has no way to communicate it back to the caller, or to identify the set of alternatives. I believe that the conversion function must return a value that represents 0, 1, or 2 time values, so that the caller is equipped to (and forced to) deal with the ambiguity after all the necessary information is available. We also need a time representation equivalent to "NaN" that permits us to talk about times shortly before the epoch. > > The third problem is that the TZ database on line is available only > > in a form that would be very clumsy to handle in an on-line transaction. > > That is, if it changes at all (which happens frequently), there is no > > way to check for rule changes in a particular locality without downloading > > the whole thing and unpacking it, which would introduce an unacceptable > > delay in an interactive application. > > Why so? A server can load single "zoneinfo" binary files as needed > from a conventional HTTP server: several could be provided around > the Internet, and intranets could have one or two available also. This seems like the beginning of a reasonable approach. Better failure tolerance than "Error 200" seems needed. Nathan Myers ncm(a)cantrip.org

3 2

time zone object
by ncm＠cantrip.org Sept. 26, 1997

Sept. 26, 1997

On Wed, 24 Sep 1997, John Cowan wrote: > I would be interested in hearing from people > who want to help improve the currently rather feeble Java 1.1 > implementation of time zones. Jeffrey Sean Connell wrote: > This couldn't possibly have come at a better time. I agree, this would be the proverbial Good Thing. I need a a similar interface for a C++ locale facet. If the level of traffic gets too great for this mailing list, we can take it off-line. I see several problems in current implementations that I would not want to propagate into an object interface. First, a 32-bit epoch would be a big mistake; we can use a "double", relative to Jan 1, 2001, which would give microsecond accuracy for now, with precision decreasing as we pass and recede from that date; or we could use a 64-bit integer count of microseconds from practically any choice of epochs. Each representation has its advantages. The second familiar problem is the crossover periods for time changes. Converting from microseconds-past-epoch to local time is well-defined; but conversion back demands accommodation to local time that doesn't exist (during "spring forward" gaps); and [2] local time that is ambiguous (before or after "fall back"). Since there isn't any really satisfactory solution to these, they just need to be visible (and unavoidable) in the interface. The third problem is that the TZ database on line is available only in a form that would be very clumsy to handle in an on-line transaction. That is, if it changes at all (which happens frequently), there is no way to check for rule changes in a particular locality without downloading the whole thing and unpacking it, which would introduce an unacceptable delay in an interactive application. To check only locally depends on "system administrators" to install updates, but most Java platforms will have (for practical purposes) no system administrator. One solution would be a network of TZ servers that can hand out up-to-date fragments of the database on demand, similar to DNS service. A good time zone class would adapt to different sources of zone information in much the way IP name lookup happens, but with fallback to a local cache when the network is inaccessible. Probably the IETF should be involved in this last bit ... do any IETF members monitor this list? Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

4 3