- tz - lists.iana.org

sri lanka timezone
by itojun＠itojun.org Oct. 15, 1997

Oct. 15, 1997

Could this be merged into FreeBSD 2.2.5-RELEASE? (and other appropriate database repositories) For details, see FreeBSD problem report #3775. http://www.freebsd.org/cgi/query-pr.cgi?pr=3775 itojun ------- Forwarded Message Return-Path: samath(a)slt.lk Return-Path: samath(a)slt.lk Received: from lakdiva.slt.lk (lakdiva.slt.lk [204.143.96.17]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id PAA10698 for <itojun(a)itojun.org>; Wed, 15 Oct 1997 15:56:53 +0900 (JST) Received: from Penta.sth.slt.lk (colombo4-tty7.slt.lk [204.143.98.135]) by lakdiva.slt.lk (8.7.5/8.7.3) with SMTP id MAA05854 for <itojun(a)itojun.org>; Wed, 15 Oct 1997 12:56:27 +0600 (GMT+0600) Message-Id: <2.2.32.19971015125504.009fcb84(a)slt.lk> X-Sender: samath(a)slt.lk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 1997 12:55:04 +0000 To: Jun-ichiro Itoh <itojun(a)itojun.org> From: Samath Wijesundera <samath(a)slt.lk> Subject: Re: conf/3775: Time Zone for Sri Lanka - LKT X-Filter: mailagent [version 3.0 PL56] for itojun(a)itojun.org Yes the time zone of Sri Lanka is now different it is GMT + 6:00 now, it will be the Sri Lanka's Permanent time zone ! The following is correct # <URL:http://www.virtual-pc.com/lankaweb/news/items/240596-2.html> (1996-05-24) # reported ``the country's standard time will be put forward by one hour at # midnight Friday (1830 GMT) `in the light of the present power crisis'.'' # Transitions before 1996 are from Shanks (1991). # # From Dharmasiri Senanayake, Sri Lanka Media Minister (1996-10-24), as quoted # in <URL:news:54rka5$m5h@mtinsc01-mgt.ops.worldnet.att.net> (1996-10-26): # With effect from 12.30 a.m. on 26th October 1996 # Sri Lanka will be six (06) hours ahead of GMT. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Colombo 5:19:24 - LMT 1880 5:20 - CEYT 1906 # Ceylon Time 5:30 - IST 1942 Jan 5 5:30 0:30 IHST 1942 Sep 5:30 1:00 IST 1945 Oct 16 2:00 5:30 - IST 1996 May 25 0:00 6:30 - LKT 1996 Oct 26 0:30 6:00 - LKT - - Samath At 02:42 PM 10/15/97 +0900, you wrote: >I don't know if it is correct, but do you mean the following >line in >http://www.freebsd.org/cgi/cvsweb.cgi/src/share/zoneinfo/asia?rev=1.11 >should be changed? > 6:30 - LKT # Sri Lanka Time > > ------- End of Forwarded Message

1 1

Does Aix support this code???
by Briggman, Monica Oct. 14, 1997

Oct. 14, 1997

Does this timezone data and code work on AIX ?? Thanks, Monica

1 0

RE: references to `africa' file for zone naming and abbrev. conve ntions.
by Olson, Arthur David Oct. 9, 1997

Oct. 9, 1997

> A minor nit, but when the zone naming and abbreviation conventions > were moved from tzdata/africa to tzcode/Theory cooresponding cross > references in the comments (See the `africa' file for time zone naming > and abbreviation conventions) comments in other data files were not > updated. Thanks for the catch. I've simply eliminated the cross references to avoid dangling pointers to a "Theory" file that some vendors may not distribute. Folks can expect to see the deletions (or rather not see them) the next time a tzdata archive goes out. --ado

1 0

references to `africa' file for zone naming and abbrev. conventions.
by J.T. Conklin Oct. 9, 1997

Oct. 9, 1997

A minor nit, but when the zone naming and abbreviation conventions were moved from tzdata/africa to tzcode/Theory cooresponding cross references in the comments (See the `africa' file for time zone naming and abbreviation conventions) comments in other data files were not updated. --jtc

1 0

RE: Proposed magic number patch
by Olson, Arthur David Oct. 8, 1997

Oct. 8, 1997

Is there a "magic number registration authority" (or an equivalent) to be in touch with either before or after deciding on one? --ado

3 2

Re: Proposed magic number patch
by ncm＠cantrip.org Oct. 8, 1997

Oct. 8, 1997

John Cowan wrote: > Chris Newman wrote: > > Excellent idea, but I'd suggest choosing a magic number based on the > > principles outlined in RFC 2083 section 12.11. I propose: > > > > \211 T Z \r \n ^Z \n > > > > as a magic number. > > Thanks for the reference to RFC 2083. I have two problems: > > 1) 7 bytes is a "peculiar" length. I suggest adding a NUL > (\0) byte just after the Z, if we go with this scheme. > In which case "strncpy" will have to be replaced with > "memcpy". > > 2) There are only 20 available bytes. I am a little > reluctant to consume 8 of them, leaving at most 3 > new 32-bit length quantities. Consuming only 4 > is less risky. I agree that seven bytes is a bit long. PNG format files suffer indignities that I don't think the TZ records need to defend against. I don't know why "^T ^Z" would be insufficient. In addition, though, I'd like to see a version sequence number too, so that if the less-than-20 bytes of slop remaining prove insufficient, we have a recourse. I maintain that advisory timestamps: - when the information was entered - when the information was last known to be current - when the information will no longer be officially trustworthy (24 hours later, by default) - when the local installation will no longer consider the information current (perhaps longer, perhaps shorter, by preference) would be a useful addition to the format, in support of incremental network caching. Of course, we should also move to a 64-bit external time representation as soon as possible, which would also be the first increment of the version sequence number. Nathan Myers ncm(a)cantrip.org

1 0

Proposed magic number patch
by John Cowan Oct. 8, 1997

Oct. 8, 1997

The following patch adds a "magic number" to compiled zoneinfo files. The affected files are zic.c and tzfile.h. In essence, the first four bytes of zoneinfo files are set to "\0x14\0x1a\0x54\0x5a", which in ASCII is "^T^ZTZ". This patch is trivial, but will assist in the automatic recognition of zoneinfo files by the Unix "file" command. *** tzfile.h Sat Jul 19 13:14:50 1997 --- tzfile.new.h Tue Oct 7 16:36:24 1997 *************** *** 46,52 **** */ struct tzhead { ! char tzh_reserved[20]; /* reserved for future use */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ --- 46,53 ---- */ struct tzhead { ! char tzh_magic[4]; /* magic string: "^T^ZTZ" */ ! char tzh_reserved[16]; /* reserved for future use */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ *** zic.c Tue Sep 23 16:37:14 1997 --- zic.new.c Tue Oct 7 16:34:30 1997 *************** *** 1468,1473 **** --- 1468,1475 ---- convert(eitol(typecnt), tzh.tzh_typecnt); convert(eitol(charcnt), tzh.tzh_charcnt); #define DO(field) (void) fwrite((void *) tzh.field, (size_t) sizeof tzh.field, (size_t) 1, fp) + strncpy(tzh.tzh_magic, "\0x14\0x1a\0x54\0x5a", 4); + DO(tzh_magic); DO(tzh_reserved); DO(tzh_ttisgmtcnt); DO(tzh_ttisstdcnt); -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org e'osai ko sarji la lojban

2 2

zoneinfo file source
by Igor Vinokurov Oct. 8, 1997

Oct. 8, 1997

re, Where I can get source of zoneinfo file? For Europe as example. -- Igor Vinokurov, JSB Inkombank

1 0

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

FW: South Africa
by Olson, Arthur David Sept. 25, 1997

Sept. 25, 1997

I don't know the basis of the "official abbreviaton" phrase in Mark's letter. --ado ---------- From: Mark R V Murray[SMTP:markm@iafrica.com] Sent: Thursday, September 25, 1997 1:49 PM To: tz(a)elsie.nci.nih.gov Hi In your timezone info for Africa, you have "invented" SAT for South African Time. Please will you change this to the official abbreviation of SAST for South African Standard Time. Countries outside South africa use the CAT, EAT, WAT etc names. Thanks! M -- Mark Murray Senior Network Engineer, UUNET Internet Africa Join the anti-SPAM movement: http://www.cauce.org

1 0

None
by Mark R V Murray Sept. 25, 1997

Sept. 25, 1997

Hi In your timezone info for Africa, you have "invented" SAT for South African Time. Please will you change this to the official abbreviation of SAST for South African Standard Time. Countries outside South africa use the CAT, EAT, WAT etc names. Thanks! M -- Mark Murray Senior Network Engineer, UUNET Internet Africa Join the anti-SPAM movement: http://www.cauce.org

1 0

Java class ADOTimeZone
by John Cowan Sept. 25, 1997

Sept. 25, 1997

I am in the process of implementing a Java 1.1 class called "ADOTimeZone" which provides support for the ADO timezone information. The different zones, compiled on a Unix system, are being included with the Java class as class-specific resources. Currently I have compilable code, but I have not yet begun component testing. When the code works, I will be giving it away freely. I would be interested in hearing from people who want to help improve the currently rather feeble Java 1.1 implementation of time zones. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org e'osai ko sarji la lojban

2 1

None
by Devang R. Vaidya Sept. 16, 1997

Sept. 16, 1997

Hello, Does anyone maintain a list of setting for the tz (timezone) parameter for various regions. For the eastern timezone of US, TZ=EST5EDT,4,1,0,3600,10,4,0,7200,3600 is being set. Thanks, Devang

1 0

Re: ISO C strftime() extention for ISO 8601
by kuhn＠cs.purdue.edu Sept. 16, 1997

Sept. 16, 1997

"Clive D.W. Feather" wrote on 1997-06-30 13:14 UTC: > You may be interested to know that WG14 adopted last week working paper > N733, which adds the following items to the strftime() function: > > %f is replaced by the weekday as a decimal number (1-7), where > Monday is 1 (the ISO 8601 weekday number). > %F is equivalent to "%Y-%m-%d" (the ISO 8601 date format). > %T is equivalent to "%H:%M:%S" (the ISO 8601 time format). > %V is replaced by the ISO 8601 week number of the year (weeks > begin on a Monday, and week 1 is the week that includes both > January 4th and the first Thursday of the year) as a decimal > number (00-53). Thanks a lot for forwarding this interesting working paper. Please forward the following comments to the authors of N733 and whoever else might be interested. If possible, I would like to review the final text of the new strftime() definition (will the current draft be on the Web somewhere?). Comments on WG14 proposal N733 ------------------------------ Markus Kuhn <kuhn(a)cs.purdue.edu> -- 1997-06-30 (= 1997-W27-1) I appreciate this proposal and I have the following related comments. a) The valid range for %V numbers is 01-53. There is no week 00 in the ISO 8601 week numbering scheme. The week before a week 01 is either week 52 or week 53 of the previous year. b) %V alone is not sufficient to be able to use the ISO week numbering system. Each week is associated with a year, the year in which the majority of the days of this week fall, and this is not necessarily the year in which all days of the weeks fall. For instance: The week 1999-W52 goes from 1999-12-27 to 2000-01-02, in other words, the day 2000-01-02 has a week notation of the form 1999-W52-7. There should be another format descriptor for the year to which the current ISO week belongs, preferably both in 4-digit (%G) and 2-digit (%g) form. If you implement an algorithm for %V, you'll get the value of %G anyway as a by-product very easily, and therefore it should be made available to the strftime() user. c) Existing practice: The Olson tzcode package <ftp://elsie.nci.nih.gov/pub/> contains a widely used strftime() implementation that supports already: %u ISO 8601 week day number (1 = Monday, 7=Sunday) %V ISO 8601 week number (01-53) %G ISO 8601 year of current week, 4-digits %g ISO 8601 year of current week, 2-digits Unless there is a good rationale for the characters suggested by N733, I would suggest to stick with %u instead of %f for the weekday number, and I hope that you will add %G and %g as used in the Olson package and Arnold Robbins' strftime version 3.0. Therefore, if I evaluate on 1977-01-02 the string %G-W%V-%u, I should get 1976-W53-7, and on 1975-12-29 I should get 1976-W01-1. Not directly related to N733, but affecting the same part of the standard, I have a number of other suggestions: d) The range for %S and tm_sec is currently defined to be 00-61 to provide for "as many as two leap seconds". This was based on a serious missunderstanding and there can never be two leap seconds per day as it becomes very obvious by reading ITU-R Recommendation TF.460-4 (I can send you a copy if you are interested). Since this 00-61 range is being widely quoted in other standards, this error should be fixed just to stop spreading this serious missconception of how leap seconds work. The correct range is 00-60. This is not an interoperability problem, but fixing this would make WG14 look like they know what they are doing, and it is therefore a good idea. e) I wonder whether %W is anywhere used and whether this field could be dropped to simplify implementation and memory cost. Countries that start the week with Monday normally use ISO 8601 week numbers (%V) and not the scheme defined by %W. I suspect %W was defined based on a missconception of how week numbers work in Europe. Unless anyone can come up with an example where %W is used or needed, I suggest to drop it as it looks completely useless to me (and please don't quote standards that just copied the %W from ISO C). f) In the definition of %y and %Y, the first two digits of a four digit year are refered to as the "century", which is problematic, since the years 1999 and 2000 belong to the 20th century, but 2001 belongs to the 21st century. Suggested better wording: "%y is replaced by the last two digits of the year as a decimal number (00-99)". Again, not a serious interoperability problem, but it makes WG14 look like they know what they are doing. g) mktime() is the inverse function of localtime(), but there exists no portable inverse function for gmtime() that converts a struct tm given in UTC into time_t. This is a serious problem, and the addition of a new function (e.g., mkgmtime() might be a possible name) should be considered seriously. It is not possible to invert gmtime() in a 100% portable way in an application program, and in practice, I have encountered awful hacks like binary searches over the time_t range to invert gmtime() in an as portable as possible way. See <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html> for further info. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

2 1

Free Submission to 620 Search Engines
by 88847271＠15831.com Sept. 13, 1997

Sept. 13, 1997

Now when you sign up for web hosting with http://www.VirtualServing.com you get free use of The Central Registry to submit your site to over 620 search engines.* http://www.VirtualServing.com provides high speed virtual website hosting services for $40.00 per month including the following: - Automatic site retrieval and conversion to our servers for new customers (in most cases) - Microsoft Front Page Server extensions - Support for Active Server Pages & Microsoft Visual InterDev - Free use of The Central Registry to submit your site to over 620 search engines* - Comprehensive monthly web site statistics - Choice of primary server country - Unlimited bandwidth usage - 5 inbound E-Mail boxes with E-Mail forwarding - FTP access with one username and password - Microsoft Access 97 - Microsoft SQL Server 6.5 - Microsoft Index Server - Microsoft Transaction Server - Microsoft Distributed Transaction Coordinator - Microsoft Certificate Server - Coming with MS Internet Information Server 4.0 in October 1997 - Ability to Administer your web site over the web - Coming with MS IIS 4.0 in October 1997 - CGI program support - Complete daily backups - One DNS mapping for your domain name - Access to raw history files - ISAPI support - 20 MB of disk storage This is a limited time offer so come to http://www.VirtualServing.com and sign up today! Thank you. * Clients must prepay the first six months of service to qualify for one time free use of The Central Registry

1 0

FW: System Time Checker
by Olson, Arthur David Sept. 11, 1997

Sept. 11, 1997

The reference to "major time zones" below is US-centric. --ado ---------- From: Hickey, Michael Sent: Thursday, September 11, 1997 9:44 AM To: TLC-L(a)LIST.NIH.GOV Subject: Re: System Time Checker Please note that these plug-ins were written specifically for Netscape. -----Original Message----- From: Fajman, Roger Sent: Wednesday, September 10, 1997 7:26 PM To: TLC-L(a)LIST.NIH.GOV Subject: System Time Checker Date: Wed, 10 Sep 1997 08:18:22 -0500 From: Gleason Sackman <gleason(a)rrnet.com> Subject: MISC> US Naval Observatorys new system-time checker Date: Tue, 09 Sep 97 21:52:34 Eastern Daylight Time From: John Tracy McGrath <jack(a)linux.cowland.com> To: gsunet list <gsunet-l(a)ecnet.net> Subject: US Naval Observatorys new system-time checker The US Naval Observatory has augmented their time-reporting service with a neat new service which compares the time being kept on your computer system with USNO time, and reports the deviation. How good are those software plug-in regulators that are supposed to keep your system time on the nose? Maybe you'll be surprised. I was! The whole process is quick and completely automatic, and you can choose from the major time zones. http://tycho.usno.navy.mil/what.html Jack McGrath ------------------------------

1 0