- tz - lists.iana.org

Re: Standard for timezone handling with TZ
by ado Feb. 14, 1994

Feb. 14, 1994

> That's a bug in the Olson rules; they aren't compatible with Posix > 1003.1-1990. Thanks for pointing it out. Here's a conservative patch > to Olson's latest version which renames `GMT-4' to `GMT-0400' to avoid > the bug. > > Another possibility is simply to remove the GMT[-+]* rules, since their > sign is the opposite of the sign in the Posix TZ string, and this is confusing. My guess is it's best to keep some sort of GMT rules; as the etcetera file notes, # All of these are set up just so people can "zic -l" to a timezone # that's right for their area, even if it doesn't have a name or dst rules # (half hour zones are too much to bother with -- when someone asks!) and if you don't have the rules you can't do the "zic -l". (Whether there should be some mechanism to establish a rule-based rather than file-based time zone as local time is another question.) > *** etcetera 1992/04/23 17:34:35 7.1 > --- etcetera 1994/02/10 19:49:45 7.1.1.1 > *************** > *** 6,55 **** > > Zone GMT 0 - GMT > > ! Zone GMT-12 -12 - GMT-1200 > ! Zone GMT-11 -11 - GMT-1100 Is it better to render these as, for example, > Zone GMT 0 - GMT > > ! Zone GMT+1200 -12 - GMT+1200 > ! Zone GMT+1100 -11 - GMT+1100 Or, given Casper H. S. Dik's example... > SunOS 4: > % env TZ=GMT-4 date GMT-4 is a timezone file (Olson) > Thu Feb 10 04:29:42 GMT-0400 1994 > % env TZ=GMT-04 date But use POSIX rules here > Thu Feb 10 12:32:21 GMT 1994 ...does POSIX *require* that the above rules be written > Zone GMT 0 - GMT > > ! Zone GMT+1200 -12 - GMT > ! Zone GMT+1100 -11 - GMT (that is, without the "+1200" modifier to the zone name that will appear in user-visible output)? --ado

3 2

Re: Standard for timezone handling with TZ
by eggert＠twinsun.com Feb. 10, 1994

Feb. 10, 1994

In comp.unix.solaris Casper H.S. Dik writes: > SunOS 4: > % env TZ=GMT-4 date GMT-4 is a timezone file (Olson) > Thu Feb 10 04:29:42 GMT-0400 1994 > % env TZ=GMT-04 date But use POSIX rules here > Thu Feb 10 12:32:21 GMT 1994 That's a bug in the Olson rules; they aren't compatible with Posix 1003.1-1990. Thanks for pointing it out. Here's a conservative patch to Olson's latest version which renames `GMT-4' to `GMT-0400' to avoid the bug. Another possibility is simply to remove the GMT[-+]* rules, since their sign is the opposite of the sign in the Posix TZ string, and this is confusing. *** etcetera 1992/04/23 17:34:35 7.1 --- etcetera 1994/02/10 19:49:45 7.1.1.1 *************** *** 6,55 **** Zone GMT 0 - GMT ! Zone GMT-12 -12 - GMT-1200 ! Zone GMT-11 -11 - GMT-1100 ! Zone GMT-10 -10 - GMT-1000 ! Zone GMT-9 -9 - GMT-0900 ! Zone GMT-8 -8 - GMT-0800 ! Zone GMT-7 -7 - GMT-0700 ! Zone GMT-6 -6 - GMT-0600 ! Zone GMT-5 -5 - GMT-0500 ! Zone GMT-4 -4 - GMT-0400 ! Zone GMT-3 -3 - GMT-0300 ! Zone GMT-2 -2 - GMT-0200 ! Zone GMT-1 -1 - GMT-0100 ! Zone GMT+1 1 - GMT+0100 ! Zone GMT+2 2 - GMT+0200 ! Zone GMT+3 3 - GMT+0300 ! Zone GMT+4 4 - GMT+0400 ! Zone GMT+5 5 - GMT+0500 ! Zone GMT+6 6 - GMT+0600 ! Zone GMT+7 7 - GMT+0700 ! Zone GMT+8 8 - GMT+0800 ! Zone GMT+9 9 - GMT+0900 ! Zone GMT+10 10 - GMT+1000 ! Zone GMT+11 11 - GMT+1100 ! Zone GMT+12 12 - GMT+1200 ! Zone GMT+13 13 - GMT+1300 # GMT+12 with DST Link GMT UTC Link GMT UCT Link GMT Universal Link GMT Greenwich Link GMT Zulu ! Link GMT GMT-0 ! Link GMT GMT+0 ! Link GMT GMT0 ! Link GMT+1 GMT1 ! Link GMT+2 GMT2 ! Link GMT+3 GMT3 ! Link GMT+4 GMT4 ! Link GMT+5 GMT5 ! Link GMT+6 GMT6 ! Link GMT+7 GMT7 ! Link GMT+8 GMT8 ! Link GMT+9 GMT9 ! Link GMT+10 GMT10 ! Link GMT+11 GMT11 ! Link GMT+12 GMT12 ! Link GMT+13 GMT13 --- 6,41 ---- Zone GMT 0 - GMT ! Zone GMT-1200 -12 - GMT-1200 ! Zone GMT-1100 -11 - GMT-1100 ! Zone GMT-1000 -10 - GMT-1000 ! Zone GMT-0900 -9 - GMT-0900 ! Zone GMT-0800 -8 - GMT-0800 ! Zone GMT-0700 -7 - GMT-0700 ! Zone GMT-0600 -6 - GMT-0600 ! Zone GMT-0500 -5 - GMT-0500 ! Zone GMT-0400 -4 - GMT-0400 ! Zone GMT-0300 -3 - GMT-0300 ! Zone GMT-0200 -2 - GMT-0200 ! Zone GMT-0100 -1 - GMT-0100 ! Zone GMT+0100 1 - GMT+0100 ! Zone GMT+0200 2 - GMT+0200 ! Zone GMT+0300 3 - GMT+0300 ! Zone GMT+0400 4 - GMT+0400 ! Zone GMT+0500 5 - GMT+0500 ! Zone GMT+0600 6 - GMT+0600 ! Zone GMT+0700 7 - GMT+0700 ! Zone GMT+0800 8 - GMT+0800 ! Zone GMT+0900 9 - GMT+0900 ! Zone GMT+1000 10 - GMT+1000 ! Zone GMT+1100 11 - GMT+1100 ! Zone GMT+1200 12 - GMT+1200 ! Zone GMT+1300 13 - GMT+1300 # GMT+12 with DST Link GMT UTC Link GMT UCT Link GMT Universal Link GMT Greenwich Link GMT Zulu ! Link GMT GMT-0000 ! Link GMT GMT+0000

1 0

Re: zic.c:mkdirs broken
by ado Feb. 10, 1994

Feb. 10, 1994

> The fix I sent before for this never made it into 94b. I don't know how > this fails to break everyone else. mkdirs is broken unless you compile > with -fwritable-strings (which is generally losing to do). > ... Thanks for the fix; it (and only it) is incorporated into tzcode94c.tar.gz on elsie.nci.nih.gov. The relevant diff is attached below. --ado SCCS/s.zic.c: 7.21 vs. 7.22 *** 7.21/zic.c Thu Feb 10 08:54:03 1994 --- 7.22/zic.c Thu Feb 10 08:54:04 1994 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.21"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.22"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1878,1890 **** } static int ! mkdirs(name) ! char * const name; { register char * cp; ! if ((cp = name) == NULL || *cp == '\0') return 0; while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix --- 1878,1892 ---- } static int ! mkdirs(argname) ! char * const argname; { + register char * name; register char * cp; ! if (argname == NULL || *argname == '\0') return 0; + cp = name = ecpyalloc(argname); while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix *************** *** 1906,1916 **** --- 1908,1920 ---- "%s: Can't create directory ", progname); (void) perror(name); + ifree(name); return -1; } } *cp = '/'; } + ifree(name); return 0; }

1 0

Re: zic.c:mkdirs broken
by Bradley White Feb. 9, 1994

Feb. 9, 1994

+ /* We must make a copy in case the + passed pointer is a read-only string. */ + char *name = ecpyalloc (argname); + if ((cp = name) == NULL || *cp == '\0') { + free (name); + return 0; + } ecpyalloc(x) [a.k.a. memcheck(icpyalloc(x))] cannot return 0. But, if you just want to program defensively, it is also good practice not to pass 0 to free(), despite what any standards might say. With the ialloc package you can achieve this via ifree(). Bradley

1 0

zic.c:mkdirs broken
by roland＠gnu.ai.mit.edu Feb. 9, 1994

Feb. 9, 1994

The fix I sent before for this never made it into 94b. I don't know how this fails to break everyone else. mkdirs is broken unless you compile with -fwritable-strings (which is generally losing to do). diff -u /home/gd3/roland/libc/time/zic.c.\~4\~ /home/gd3/roland/libc/time/zic.c --- /home/gd3/roland/libc/time/zic.c.~4~ Mon Feb 7 14:30:53 1994 +++ /home/gd3/roland/libc/time/zic.c Wed Feb 9 14:09:11 1994 @@ -1877,14 +1877,20 @@ charcnt += eitol(i); } + static int -mkdirs(name) -char * const name; +mkdirs(argname) +char * const argname; { register char * cp; + /* We must make a copy in case the + passed pointer is a read-only string. */ + char *name = ecpyalloc (argname); - if ((cp = name) == NULL || *cp == '\0') - return 0; + if ((cp = name) == NULL || *cp == '\0') { + free (name); + return 0; + } while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix @@ -1906,11 +1912,13 @@ "%s: Can't create directory ", progname); (void) perror(name); + free (name); return -1; } } *cp = '/'; } + free (name); return 0; } Diff exited abnormally with code 1 at Wed Feb 9 14:09:45

1 0

leap seconds [forwarded with permission from wollman@uvm-gen.emba.uvm.edu]
by ado Feb. 7, 1994

Feb. 7, 1994

> From wollman(a)uvm-gen.EMBA.UVM.EDU Sun Feb 6 17:45:52 1994 > Return-Path: <wollman(a)uvm-gen.EMBA.UVM.EDU> > Received: from bajoran.emba.uvm.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA18437; Sun, 6 Feb 94 17:45:51 EST > Received: by bajoran.emba.uvm.edu id AA18471 > (5.65/6.05); Sun, 6 Feb 94 17:45:50 -0500 > Date: Sun, 6 Feb 94 17:45:50 -0500 > From: wollman(a)uvm-gen.EMBA.UVM.EDU > Message-Id: <9402062245.AA18471(a)bajoran.emba.uvm.edu> > To: ado(a)elsie.nci.nih.gov > Subject: Re: timezone servers > Newsgroups: comp.protocols.time.ntp > In-Reply-To: <1994Feb4.234532.26832(a)alw.nih.gov> > References: <199402020109.AA01671(a)ni.umd.edu> > Organization: University of Vermont, EMBA Computer Facility > > ...According to the bulletins that I've seen, |TAI-UTC| is about > 28 seconds now. However, the leapseconds file only lists 19 steps. > This is probably due to the fact that the first step was 10 seconds, > not just 1. Is there an easy way to fix this, so my users who use NTP > don't complain about their clocks being nine seconds off? > > -GAWollman > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman(a)emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. > NB: Address soon to | It is a bond more powerful than absence. We like people > be changed. | who like Shashish. - Claude McKenzie + Florent Vollant

4 3

tzcode94b.tar.gz and tzdata94b.tar.gz
by ado Feb. 7, 1994

Feb. 7, 1994

Updated time zone code and data is available by anonymous ftp from elsie.nci.nih.gov (128.231.16.1) in the "pub" directory; the culprits are -rw-r--r-- 1 ado 62145 Feb 7 10:04 tzcode94b.tar.gz -rw-r--r-- 1 ado 63993 Feb 7 10:04 tzdata94b.tar.gz The updates are the work by Paul Eggert (eggert(a)twinsun.com) who notes: > I found another book of time zone histories by E W Whitman; it's not as > extensive as Shanks but has a few goodies of its own. I used it to > update the tables. I also fixed some more as a result of > correspondence with Adam David and Peter Ilieve, and move some stray > links from `europe' to `backward'. I corrected some scanning errors in > usno1989. > > As far as the code goes, I fixed zic to allow years in the range > INT_MIN to INT_MAX; this fixed a few boundary conditions around 1900. > And I cleaned up the zic documentation a little bit. --ado

1 0

tzdata94a.tar.gz
by ado Feb. 3, 1994

Feb. 3, 1994

tzdata94a.tar.gz is now available on elsie.nci.nih.gov; it simply incorporates the recently announced leap second into the "leapseconds" file. For those who want to forego a trip to the ftp well, a diff from the previous version is attached. --ado SCCS/s.leapseconds: 7.6 vs. 7.7 *** 7.6/leapseconds Thu Feb 3 09:02:22 1994 --- 7.7/leapseconds Thu Feb 3 09:02:22 1994 *************** *** 1,4 **** ! # @(#)leapseconds 7.6 # Allowance for leapseconds added to each timezone file. --- 1,4 ---- ! # @(#)leapseconds 7.7 # Allowance for leapseconds added to each timezone file. *************** *** 38,40 **** --- 38,41 ---- Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S + Leap 1994 Jun 30 23:59:60 + S

1 0

time zones [forwarded with permission]
by ado Jan. 5, 1994

Jan. 5, 1994

> From ncm(a)netcom.com Wed Jan 5 03:20:09 1994 > Return-Path: <ncm(a)netcom.com> > Received: from mail.netcom.com (netcom3.netcom.com) by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA17468; Wed, 5 Jan 94 03:20:07 EST > Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) > id AAA02279; Wed, 5 Jan 1994 00:20:40 -0800 > Date: Wed, 5 Jan 1994 00:20:40 -0800 > From: ncm(a)netcom.com (Nathan Myers) > Message-Id: <199401050820.AAA02279(a)mail.netcom.com> > To: ado(a)elsie.nci.nih.gov > Subject: time zones > Status: RO > > Hello, > > I have been working on time zones at Rogue Wave Software, and > on locale support for the ISO/ANSI C++ Standard Library committee. > It seems to me that the C++ Library effort offers an excellent > place to standardize on a time zone library, as the contents > of a class timezone. We are not bound to C Library facilities > or conventions, so this is an opportunity to correct old mistakes. > (e.g. hidden static variables implied by the interface) > > Please forward this to anyone you think might be interested in > helping put together a proposal. > > Thank you > Nathan Myersn > myersn(a)roguewave.com

1 0

Re: Iceland's timezone
by Adam David Dec. 9, 1993

Dec. 9, 1993

> # time the norsemen first settled Iceland. The first day of winter is always > # Saturday, but is not dependent on the Julian or Gregorian calendars. I will try and find a general rule for this, but it may take awhile. > # We go with the Almanak, except for two claims from Shanks: > # 1. In 1968 standard time wasn't switched to GMT until Oct 27; > # this affects only the time zone name and dst flag. I wonder if this one is such a good idea. Here is the actual quote from the almanak (paraphrased): In the year 1968 "summer time" was finally made standard time in Iceland by law number 6 from April 5th that year. The change was made on April 7th at 2:00 GMT and the clock was adjusted forwards by one hour. Clock time in Iceland has since then been on GMT the whole year round. Of course, both Shanks and the Almanak have the same actual time offset for summer 1968, but technically it is the Almanak that is correct. Shanks chooses October 27th as the transition time because that is when the end of the summer time would otherwise have been (by the previous general rule). -- Adam David <adam(a)veda.is>

1 0

Iceland's timezone
by yata!eggert＠twinsun.com Dec. 9, 1993

Dec. 9, 1993

Thanks for looking up the U of Iceland Almanak. Here's how I translated what you wrote into tzfile format; I'll include this in the next set of revisions that I propose to ado. # Iceland # # From Adam David <adam(a)veda.is> (November 6, 1993): # The name of the timezone in Iceland for system / mail / news purposes is GMT. # # (December 5, 1993): # This material is paraphrased from the 1988 edition of the University of # Iceland Almanak. # # From January 1st, 1908 the whole of Iceland was standardised at 1 hour # behind GMT. Previously, local mean solar time was used in different parts # of Iceland, the almanak had been based on Reykjavik mean solar time which # was 1 hour and 28 minutes behind GMT. # # "first day of winter" referred to [below] means the first day of the 26 weeks # of winter, according to the old icelandic calendar that dates back to the # time the norsemen first settled Iceland. The first day of winter is always # Saturday, but is not dependent on the Julian or Gregorian calendars. # # From Paul Eggert <eggert(a)twinsun.com> (December 9, 1993): # The Iceland Almanak, Shanks and Whitman disagree on many points. # We go with the Almanak, except for two claims from Shanks: # 1. In 1968 standard time wasn't switched to GMT until Oct 27; # this affects only the time zone name and dst flag. # 2. Reykavik was -1:28 from 1837 to 1908, local mean time before that. # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Iceland 1908 only - Jan 1 0:00 0 S Rule Iceland 1917 1918 - Feb 19 23:00 1:00 D Rule Iceland 1917 only - Oct 21 1:00 0 S Rule Iceland 1918 only - Nov 16 1:00 0 S Rule Iceland 1939 only - Apr 29 23:00 1:00 D Rule Iceland 1939 only - Nov 29 2:00 0 S Rule Iceland 1940 only - Feb 25 2:00 1:00 D Rule Iceland 1940 only - Nov 3 2:00 0 S Rule Iceland 1941 only - Mar 2 1:00s 1:00 D Rule Iceland 1941 only - Nov 2 1:00s 0 S Rule Iceland 1942 only - Mar 8 1:00s 1:00 D Rule Iceland 1942 only - Oct 25 1:00s 0 S # 1943-1946 - first Sunday in March until first Sunday in winter Rule Iceland 1943 1946 - Mar Sun>=1 1:00s 1:00 D Rule Iceland 1943 1948 - Oct Sun>=22 1:00s 0 S # 1947-1967 - first Sunday in April until first Sunday in winter Rule Iceland 1947 1968 - Apr Sun>=1 1:00s 1:00 D # 1949 Oct transition delayed by 1 week Rule Iceland 1949 only - Oct 30 1:00s 0 S Rule Iceland 1950 1966 - Oct Sun>=22 1:00s 0 S Rule Iceland 1967 only - Oct 29 1:00s 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Reykjavik -1:27:24 - LMT 1837 -1:28 - RMT 1908 # Reykjavik Mean Time -1:00 Iceland I%sT 1968 Oct 27 1:00s 0:00 - GMT

1 0

Re: Iceland's timezone
by Adam David Dec. 6, 1993

Dec. 6, 1993

Sorry about the delay getting back with this information. > I'm working on a rewrite of `europe' with a large set of historical > data. My current draft (see below) claims that Iceland changed its > timezone in 1968. I've taken this claim from Thomas G. Shanks, The > international atlas (3rd edition), San Diego: ACS Publications, Inc. > (1991). If you have some better data, please let me know. In a way, there was a timezone change in 1968, where the summertime change was applied during the spring, and became the all-year-round time, and there have been no changes since then, not for DST or any other reason. When looking back to previous years when there was DST, icelanders tend to refer to the concept of "winter time", as the summer time had the same offset as the present all-year-round time. This is why I was led to believe that no timezone change had taken place in 1968. > It would be nice to know what time zone abbreviations were used before > 1968, since Shanks doesn't say. In the following table I've made up > the names `IST', `IDT', `RMT', and `LMT' for Iceland Standard Time, > Iceland Daylight Time, Reykjavik Mean Time, and Local Mean Time > respectively. I have no details of any abbreviations, sorry. > # From Shanks (1991): > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Iceland 1908 only - Jan 1 0:00 0 S > Rule Iceland 1917 1918 - Feb 20 2:00 1:00 D > Rule Iceland 1917 only - Oct 25 2:00 0 S > Rule Iceland 1918 1919 - Nov 15 2:00 0 S > Rule Iceland 1919 only - Feb 19 2:00 1:00 D > Rule Iceland 1921 only - Mar 19 2:00 1:00 D > Rule Iceland 1921 only - Jun 22 2:00 0 S > Rule Iceland 1941 1942 - Mar Sat>=1 2:00 1:00 D > Rule Iceland 1941 1942 - Jul 2 2:00 0 S > Rule Iceland 1943 1946 - Mar Sun>=1 2:00 1:00 D > Rule Iceland 1943 1948 - Oct Sun>=22 2:00 0 S > Rule Iceland 1947 1962 - Apr Sun>=1 2:00 1:00 D > Rule Iceland 1949 only - Oct 30 2:00 0 S > Rule Iceland 1950 only - Oct 22 2:00 0 S > # From Paul Eggert <eggert(a)twinsun.com> (November 10, 1993): > # Shanks's ``1953 Oct 26'' is probably a typo for Oct 25. > # Likewise, correct Shanks's ``1961 Oct 22'' to Oct 29. > Rule Iceland 1951 1967 - Oct Sun>=23 1:00s 0 S > Rule Iceland 1963 1968 - Apr Sun>=1 1:00s 1:00 D > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > Zone Atlantic/Iceland/Reykjavik -1:27:24 - LMT 1837 Jan 1 > -1:28 - RMT 1908 Jan 1 > -1:00 Iceland I%sT 1968 Oct 27 1:00s > 0:00 - GMT > # This link is for backward compatibility with the old naming convention. > Link Atlantic/Iceland/Reykjavik Iceland I don't feel up to messing with this table and submitting a corrected version. Here I copy a list of periods when summertime was active, and explanatory text. This material is paraphrased from the 1988 edition of the University of Iceland Almanak. >From January 1st, 1908 the whole of Iceland was standardised at 1 hour behind GMT. Previously, local mean solar time was used in different parts of Iceland, the almanak had been based on Reykjavik mean solar time which was 1 hour and 28 minutes behind GMT. Summertime when it was applied was always by putting the clock an hour forward during the summer months, which made the clock time equal to GMT. The following list shows when this summertime was in force. The time of the clock change is specified in GMT. year from to ---- ---- -- 1908-1916 no summertime 1917 20.Feb. 0:00 21.Oct. 1:00 1918 20.Feb. 0:00 16.Nov. 1:00 1919-1938 no summertime 1939 30.Apr. 0:00 29.Nov. 2:00 1940 25.Feb. 3:00 3.Nov. 2:00 1941 2.Mar. 2:00 2.Nov. 2:00 1942 8.Mar. 2:00 25.Oct. 2:00 1943-1946 rule (first Sunday in March until first Sunday in winter) 1943 7.Mar. 2:00 24.Oct. 2:00 1944 5.Mar. 2:00 22.Oct. 2:00 1945 4.Mar. 2:00 28.Oct. 2:00 1946 3.Mar. 2:00 27.Oct. 2:00 1947-1967 rule (first Sunday in April until first Sunday in winter) 1947 6.Apr. 2:00 26.Oct. 2:00 1948 4.Apr. 2:00 24.Oct. 2:00 1949 3.Apr. 2:00 ******* 30.Oct. 2:00 (delayed by 1 week) 1950 2.Apr. 2:00 22.Oct. 2:00 1951 1.Apr. 2:00 28.Oct. 2:00 1952 6.Apr. 2:00 26.Oct. 2:00 1953 5.Apr. 2:00 25.Oct. 2:00 1954 4.Apr. 2:00 24.Oct. 2:00 1955 3.Apr. 2:00 23.Oct. 2:00 1956 1.Apr. 2:00 28.Oct. 2:00 1957 7.Apr. 2:00 27.Oct. 2:00 1958 6.Apr. 2:00 26.Oct. 2:00 1959 5.Apr. 2:00 25.Oct. 2:00 1960 3.Apr. 2:00 23.Oct. 2:00 1961 2.Apr. 2:00 22.Oct. 2:00 1962 1.Apr. 2:00 28.Oct. 2:00 1963 7.Apr. 2:00 27.Oct. 2:00 1964 5.Apr. 2:00 25.Oct. 2:00 1965 4.Apr. 2:00 24.Oct. 2:00 1966 3.Apr. 2:00 23.Oct. 2:00 1967 2.Apr. 2:00 29.Oct. 2:00 1968 7.Apr. 2:00 (actually GMT after this) "first day of winter" referred to above, means the first day of the 26 weeks of winter, according to the old icelandic calendar that dates back to the time the norsemen first settled Iceland. The first day of winter is always Saturday, but is not dependent on the Julian or Gregorian calendars. This is the reason for the discrepancy with October 1961. I can find out more exactly how to determine when it falls, if necessary. It is a pity I don't have that information handy, otherwise I could include it here. There are more serious discrepancies before 1941 which are not obviously explainable. What to do... (?) -- Adam David <adam(a)veda.is>

1 0

Re: Timezone rule change in Europe [forwarded from Dik Winter]
by Dik.Winter＠cwi.nl Dec. 3, 1993

Dec. 3, 1993

> Has anyone got precise details of the dates? i.e last sunday in october, or > last sunday after 23rd October (like uk) The paper was a bit unclear about that; the text was conflicting. On the one hand it talked about the current UK rule, on the other hand it talked about the last sunday in October. But I presume the rule now valid in the UK will be adopted by the remainder of the EU. So that would be first sunday after 23rd October. I will report about it when I know more. dik

1 0

Re: Timezone rule change in Europe [forwarded from Dik Winter]
by Glenn.Wright＠UK.Sun.COM Dec. 3, 1993

Dec. 3, 1993

Has anyone got precise details of the dates? i.e last sunday in october, or last sunday after 23rd October (like uk) Glenn. > > The ministers of transport of the European Union (formerly European > Community) have decided that by 1997 change from summer time to > winter time will be made by the end of october instead of the end > of september. This will bring the remainder of the EU in line with > the current rule in the United Kingdom and Ireland. It is to be expected > that other European countries will follow. [This according of my > paper of todaty, December 1.] > > (The European Union consists of: Netherlands, Belgium, Luxembourg, > France, Germany, Italy, United Kingdom, Ireland, Danmark, Spain, > Portugal and Greece.)

1 0

Timezone rule change in Europe [forwarded from Dik Winter]
by ado Dec. 2, 1993

Dec. 2, 1993

> From daemon(a)ncifcrf.gov Thu Dec 2 13:51:20 1993 > Return-Path: <daemon(a)ncifcrf.gov> > Received: from fcs280s.ncifcrf.gov by elsie (4.1/SMI-4.1) > id AA12625; Thu, 2 Dec 93 13:51:19 EST > Received: by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA04025; Thu, 2 Dec 93 13:43:34 GMT > Received: from charon.cwi.nl by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA04003; Thu, 2 Dec 93 13:43:28 GMT > Received: from boring.cwi.nl by charon.cwi.nl with SMTP > id AA02005 (5.65b/3.12/CWI-Amsterdam); Wed, 1 Dec 1993 22:07:42 +0100 > Received: by boring.cwi.nl > id AA12403 (4.1/2.10/CWI-Amsterdam); Wed, 1 Dec 93 22:07:42 +0100 > Date: Wed, 1 Dec 93 22:07:42 +0100 > From: Dik.Winter(a)cwi.nl > Message-Id: <9312012107.AA12403.dik(a)boring.cwi.nl> > To: ado(a)ncifcrf.gov > Subject: Timezone rule change in Europe > Status: RO > > The ministers of transport of the European Union (formerly European > Community) have decided that by 1997 change from summer time to > winter time will be made by the end of october instead of the end > of september. This will bring the remainder of the EU in line with > the current rule in the United Kingdom and Ireland. It is to be expected > that other European countries will follow. [This according of my > paper of todaty, December 1.] > > (The European Union consists of: Netherlands, Belgium, Luxembourg, > France, Germany, Italy, United Kingdom, Ireland, Danmark, Spain, > Portugal and Greece.) > > dik > -- > dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland > home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik(a)cwi.nl

1 0

tzcode93g.tar.gz and tzdata93g.tar.gz
by ado Nov. 29, 1993

Nov. 29, 1993

The files tzcode93g.tar.gz and tzdata93g.tar.gz are now available for anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (128.231.16.1). Paul Eggert has provided a good deal of historic information (based on Shanks), and there are some code changes to deal with the buglets that crawled out in dealing with the new information. --ado

1 0

Iceland's timezone
by yata!eggert＠twinsun.com Nov. 11, 1993

Nov. 11, 1993

From: Adam David <adam(a)veda.is> To: wollman(a)uvm-gen.emba.uvm.edu Date: Sat, 6 Nov 1993 21:50:43 +0000 (GMT) Iceland has not changed timezone since 1900 and has not had Summer Time since quite a long time ago, probably before 1970. If you want exact dates for summertime that long ago, I will find this out for you. I'm working on a rewrite of `europe' with a large set of historical data. My current draft (see below) claims that Iceland changed its timezone in 1968. I've taken this claim from Thomas G. Shanks, The international atlas (3rd edition), San Diego: ACS Publications, Inc. (1991). If you have some better data, please let me know. It would be nice to know what time zone abbreviations were used before 1968, since Shanks doesn't say. In the following table I've made up the names `IST', `IDT', `RMT', and `LMT' for Iceland Standard Time, Iceland Daylight Time, Reykjavik Mean Time, and Local Mean Time respectively. # Iceland # # From Adam David <adam(a)veda.is> (November 6, 1993): # The name of the timezone in Iceland for system / mail / news purposes is GMT. # # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Iceland 1908 only - Jan 1 0:00 0 S Rule Iceland 1917 1918 - Feb 20 2:00 1:00 D Rule Iceland 1917 only - Oct 25 2:00 0 S Rule Iceland 1918 1919 - Nov 15 2:00 0 S Rule Iceland 1919 only - Feb 19 2:00 1:00 D Rule Iceland 1921 only - Mar 19 2:00 1:00 D Rule Iceland 1921 only - Jun 22 2:00 0 S Rule Iceland 1941 1942 - Mar Sat>=1 2:00 1:00 D Rule Iceland 1941 1942 - Jul 2 2:00 0 S Rule Iceland 1943 1946 - Mar Sun>=1 2:00 1:00 D Rule Iceland 1943 1948 - Oct Sun>=22 2:00 0 S Rule Iceland 1947 1962 - Apr Sun>=1 2:00 1:00 D Rule Iceland 1949 only - Oct 30 2:00 0 S Rule Iceland 1950 only - Oct 22 2:00 0 S # From Paul Eggert <eggert(a)twinsun.com> (November 10, 1993): # Shanks's ``1953 Oct 26'' is probably a typo for Oct 25. # Likewise, correct Shanks's ``1961 Oct 22'' to Oct 29. Rule Iceland 1951 1967 - Oct Sun>=23 1:00s 0 S Rule Iceland 1963 1968 - Apr Sun>=1 1:00s 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Atlantic/Iceland/Reykjavik -1:27:24 - LMT 1837 Jan 1 -1:28 - RMT 1908 Jan 1 -1:00 Iceland I%sT 1968 Oct 27 1:00s 0:00 - GMT # This link is for backward compatibility with the old naming convention. Link Atlantic/Iceland/Reykjavik Iceland

1 0

Re: Specifications for Iceland's timezone [forwarded]
by ado Nov. 9, 1993

Nov. 9, 1993

> From wollman(a)uvm-gen.EMBA.UVM.EDU Sat Nov 6 17:01:21 1993 > Return-Path: <wollman(a)uvm-gen.EMBA.UVM.EDU> > Received: from sadye.emba.uvm.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA20235; Sat, 6 Nov 93 17:01:19 EST > Received: by sadye.emba.uvm.edu id AA06301 > (5.65/1.23); Sat, 6 Nov 93 17:00:22 -0500 > Date: Sat, 6 Nov 93 17:00:22 -0500 > From: wollman(a)uvm-gen.EMBA.UVM.EDU > Message-Id: <9311062200.AA06301(a)sadye.emba.uvm.edu> > To: ado(a)elsie.nci.nih.gov > Subject: Specifications for Iceland's timezone > Status: RO > > One of the FreeBSD team members in Iceland reports the following > complaints with the default `Iceland' timezone as supplied in your > latest `europe' file: > > ------- Start of forwarded message ------- > From: Adam David <adam(a)veda.is> > To: wollman(a)uvm-gen.emba.uvm.edu > Subject: Re: New timezone code > Date: Sat, 6 Nov 1993 21:50:43 +0000 (GMT) > > [stuff deleted by me -GW] > > The problem with WET is that WET is used also in the British Isles, and > some systems might assume BST by default if they see "WET" during the summer > months. The name of the timezone in Iceland for system / mail / news purposes > is GMT. [...] > > > If Iceland has ever observed Summer Time or has changed time > > zones at any time in the past, I'd appreciate knowing about it, so we > > can update the files and send the corrections to Arthur David Olson. > > Iceland has not changed timezone since 1900 and has not had Summer Time > since quite a long time ago, probably before 1970. If you want exact dates > for summertime that long ago, I will find this out for you. > > [...] > ------- End of forwarded message ------- > > -GAWollman > > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman(a)emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. > uvm-gen!wollman | It is a bond more powerful than absence. We like people > UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant

1 0

possible time zone file syntax extension
by ado Nov. 5, 1993

Nov. 5, 1993

There's work in progress on adding historical information to time zone files. It might be useful to extend the syntax of "UNTIL" parts so that you could write something such as # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone This 0:00 - TST 1916 May 21 2:00s 0:00 Whatever T%sT 1968 Feb 18 2:00s->That where the "->That" on the final line means "after the UNTIL time, use whatever happens in Zone 'That'." This would both allow for more concise representation of historic information and allow a "-c" (or some other letter) flag to zic that would tell it to only compile "current" zones--zones that did NOT end with a line containing "->". If you have insights on whether this is the best thing to do, I'd love it if you'd share them with folks on the time zone mailing list. --ado

1 0

proposal for time zone names
by eggert＠twinsun.com Oct. 20, 1993

Oct. 20, 1993

I thought a bit about the problem of the explosion of time zone names, since we're looking at time zone rules for everywhere from Afghanistan to Zimbabwe. What do people think about time zone names of the from MAJOR_REGION/COUNTRY/CITY, e.g.: Africa/Zimbabwe/Harare Asia/Afghanistan/Kabul Europe/Albania/Tirana North_America/US/Los_Angeles Pacific/Fiji/Suva The ``major regions'' would be continents (Africa, North_ and South_ America, Antarctica, Australia, Asia, Europe) and oceans (Antarctic, Artic, Atlantic, Indian, Pacific). The ``minor regions'' would typically be countries. Only present-day English names for regions and cities would be used. The advantage of going to the detail of CITY is that we can use local mean time for times before standard time was introduced (e.g. before 1914 Jan 1 in Albania); this increases the accuracy of the database. Of course we should maintain links to traditional names like `Japan' and `US/Eastern' for backwards compatibility. Since I last wrote, I've coded up two sample countries. Asia/Afghanistan/Kabul needed just two lines of rules; Shanks says they've changed the rules only once since they adopted standard time in 1890. Europe/Albania/Tirana is a much more complicated 35-liner. Not only did it suffer the time zone vagaries of World War II, but also its dictatorship fiddled with the clocks seemingly at random between 1974 and 1984 before finally switching to the Polish rules. It looks like this will take some time.

1 0

problems with zoneinfo package passing VSX4 [forwarded with permission from grant@osf.org]
by ado Oct. 20, 1993

Oct. 20, 1993

> From grant(a)osf.org Tue Oct 19 17:47:42 1993 > Return-Path: <grant(a)osf.org> > ... > Message-Id: <9310192147.AA24813(a)postman.osf.org> > To: ado(a)elsie.nci.nih.gov > Cc: grant(a)osf.org > Subject: problems with zoneinfo package passing VSX4 > Date: Tue, 19 Oct 1993 21:47:37 +0000 > From: Grant Sullivan <grant(a)osf.org> > ... > > I am a contract software engineer currently working for the Open Software > Foundation, Cambridge, MA. I last sent mail to you in August of this year > regarding my project to upgrade the next OSF/1 release to include the > zoneinfo package. > > I ended up using a sort of cut & paste approach to the project, using > the BSD 4.4 version of ctime.c, based on your earlier work, as my code > base for the libc changes, and "zic" additions. I compared those sources > with your June '93 kit, and merged in what appeared to be fixes. I also > included your entire June '93 zoneinfo source files. I had to make a few > other changes here and there to integrate everything into OSF/1. > > As a final functional check of libc, I was asked to run the VSX4 test > suite, before I would be allowed to formally submit the entire package > into the OSF/1 source pool. > > The VSX4 test suite found some problems with ctime(), localtime(), mktime(), > strftime() and tzset(). Most of these problems turned out to have a single > cause. For example, correcting the failure in ctime() fixed the problems > with localtime(), strftime(), tzset(), and some of the mktime() problems. > I thought you might be interested in knowing what changes I had to make to > pass VSX4. I am also stuck with one problem in mktime(), which you should > be aware of, and for which I am having trouble developing a solution. > > The VSX4 failure in ctime() involved a test case where TZ was set to > TZ=(255 A's)0(255 B's) > The number "255" corresponds to the POSIX.1 value for TZNAME_MAX. > The VSX4 ANSI.os/time/ctime/T.ctime test Assertion 11 failed when the > test checked the contents of tzname[] to see if it contained long A and > B strings. ctime() failed because tzset() return an error when it > found that the value of stdlen+1+dstlen+1 was greater than sizeof sp->chars. > The sizeof sp->chars was TZ_MAX_CHARS, set to "50" in tzfile.h. I reset > TZ_MAX_CHARS to 2*(TZNAME_MAX+1), in order to fix the VSX4 failure. > Additionally in tzparse(), I changed the size checks for "stdlen" and > "dstlen" to include upper limit checks against TZNAME_MAX, as follows: > . > . > } else { > name = getzname(name); > stdlen = name - stdname; > if ( stdlen < _POSIX_TZNAME_MAX || stdlen > TZNAME_MAX ) > return -1; > . > . > dstlen = name - dstname; /* length of DST zone name */ > if ( dstlen < _POSIX_TZNAME_MAX_POSIX_TZNAME_MAX || dstlen > TZNAME_MAX ) > return -1; > . > . > I also replaced "3" with _POSIX_TZNAME_MAX aboce. The additional limit > checks also make sure that the sum of the "std" and "dst" fields will > not exceed 2*(TZNAME_MAX+1) even if TZ_MAX_CHARS should be set to > something smaller. > > The changes to tzfile.h and tzparse() resulted in eliminating the VSX4 > failures of ctime(), localtime(), strftime(), tzset(), and some of the > mktime() failures. > > I have some temporary fixes for the mktime() failures, but I have not > been able to successfully fix the VSX4 failure of > ANSI.os/time/mktime/T.mktime assertion 10. Attempts I've made to fix > it have tended to cause other mktime() assertions to fail, and vice > versa. I suspect a flaw in the loop logic, or loop termination logic > in time2(), but it could also be a flaw in time1() or in localsub(). > > The VSX4 test of mktime fails when: > TZ=GMT0BST-2,J81,J300 > and mktime() is called with the following tm structure: > expected.tm_sec = 21; > expected.tm_min = 0; > expected.tm_hour = 2; > expected.tm_mday = 27; > expected.tm_mon = 9; > expected.tm_year = 88; > expected.tm_wday = -1; > expected.tm_yday = -1; > expected.tm_isdst = 1; > VSX4 is expecting mktime() to return a value in the range 593913621 - > 593913631 (allowing for the possibility that mktime() may include up to > 10 additional leap seconds. mktime() returned -1, instead. > > I believe the expected value is correct. VSX4 validates the mktime() > returned value by calling localtime() with the expected number and > comparing the expected and localtime()-generated tm structures. > > I believe that VSX4 is expecting mktime() to behave in accordance to > XPG4 with regards to how tm_isdst = 1 is handled on input to mktime(). > XPG4, "System Interfaces and Headers", page 275, says: > A positive or zero value for tm_isdst causes the mktime() > function to presume initially that Daylight Savings Time, > respectively, is or is not in effect for the specified time. > ... > mktime() seems to be having trouble when tm_isdst = 1, but the time/day > the tm data specified is just past the end of the daylight savings time > period. In the case above, the time is 21 seconds past the transition > back to standard time. > > I have tried things like resetting tm_isdst = 0 and recalculating, but > that works for some cases exercised by VSX4, but not for this > particular case. > > Have you heard of this VSX4 case? > > One area that is suspect is the extended loop in time2() which is based > on the "bits" counter. The comments above the "normalize" function > appear to pertain to this loop in time2(): > > /* > ** Adapted from code provided by Robert Elz, who writes: > ** The "best" way to do mktime I think is based on an idea of Bob > ** Kridle's (so its said...) from a long time ago. (mtxinu!kridle now). > ** It does a binary search of the time_t space. Since time_t's are > ** just 32 bits, its a max of 32 iterations (even at 64 bits it > ** would still be very reasonable). > */ > > I've added debugging statements to time2() to better understand what > the "bits" logic is about, and found that "bits" counter would often > get down to as low as "5" before jumping down to the next "for" loop. > For the case tested by VSX4, timecnt = 136, so if this were truly "a > binary search of the time_t space", I would not expect "bits" to drop > below 21. For the VXS4 test case, however, bits = 5 by the time the > loop has found a value of "t" that is in range (t=593920800). The > calculates to a linear search, rather than a binary search, since the > matching t = (sp->ats[37] + tt_gmtoff), and (37/2) is approx. (88-70) > is approx. (initial bits - final bits ) (31 - 5). I've tried setting > the tm_year = 92, however, and found the loop went through the same > number of cycles, so it I guess the search isn't really linear, but it > seems to me it could be faster. > > > I also noticed that your June '93 kit's version of timesub() contains > additional code vs. the BSD 4.4 version. I am wondering if this > additional code is a bug fix? > > Thanks for your assistance, > Grant W. Sullivan, > OSF/1 Commands & Libraries Group > Open Software Foundation > 11 Cambridge Center > Cambridge, MA 02142 > grant(a)osf.org > 617) 621-7249

1 0

Re: Shank's International Atlas [forwarded with permission from eggert@twinsun.com]
by ado Oct. 20, 1993

Oct. 20, 1993

> From twinsun!twinsun.com!eggert(a)CS.UCLA.EDU Tue Oct 19 18:07:51 1993 > Return-Path: <twinsun!twinsun.com!eggert(a)CS.UCLA.EDU> > ... > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9310192204.AA24829(a)spot.twinsun.com> > Date: 19 Oct 1993 15:04:24 -0700 > To: ado(a)elsie.nci.nih.gov > In-Reply-To: <9310192039.AA26353(a)elsie.nci.nih.gov> (ado(a)elsie.nci.nih.gov) > Subject: Re: Shanks's International Atlas > ... > > That being so, we'd want to be on the lookout for rare timekeeping > changes and be sure to include them. > > Yes, definitely. (Ireland was an eye-opener for me.) > > 2. A pragmatic answer to how many zones to have for France is "as many as > are needed to describe the present day zones." As you noted, though, > doing even this at the country level yields lots of zones. > > If we were to do this, we'd need a convention to help decide which of the 153 > zone histories we'd present as `France'. I see two plausible options: pick > the present-day capital (i.e. Paris), or pick the most typical and widely-used > (for France, this would probably be Shanks's French Time Zone #1, which I > believe is the time zone history of the un-fought-over boondocks during the > two world wars). > > 3. As a last resort, simply reporting UCT for a zone when it's doing > something awkward is a possibility. > > If by `awkward' you mean LMT, I'd prefer using standard time instead, since > it's less of an error. E.g. if we use the district's present-day capital for > (2), then we could use the capital's LMT for times before standard time was > instituted. > > If we use present-day capitals, I think it'd be far more honest to give time > zone files names like `Paris' and `Berlin' instead of `France' and `Germany'. > This is reminiscent of the interface used in the HP 100LX palmtops -- they ask > you what city you're in, not what country you're in.

1 0

Re: Shank's International Atlas
by ado Oct. 20, 1993

Oct. 20, 1993

Some initial feedback. 1. The notion in the README file is that > Historical local time information has been included here not because it > is particularly useful, but rather to: > > * give an idea of the variety of local time rules that have > existed in the past and thus an idea of the variety that may be > expected in the future; > > * provide a test of the generality of the local time rule description > system. That being so, we'd want to be on the lookout for rare timekeeping changes and be sure to include them. 2. A pragmatic answer to how many zones to have for France is "as many as are needed to describe the present day zones." As you noted, though, doing even this at the country level yields lots of zones. 3. As a last resort, simply reporting UCT for a zone when it's doing something awkward is a possibility. --ado

1 0

Shanks's International Atlas [forwarded with permission from eggert@twinsun.com]
by ado Oct. 20, 1993

Oct. 20, 1993

> From twinsun!twinsun.com!eggert(a)CS.UCLA.EDU Tue Oct 19 15:08:13 1993 > Return-Path: <twinsun!twinsun.com!eggert(a)CS.UCLA.EDU> > ... > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9310191858.AA24533(a)spot.twinsun.com> > Date: 19 Oct 1993 11:58:24 -0700 > To: ado(a)elsie.nci.nih.gov > Subject: Shanks's International Atlas > ... > > In looking through Shanks's atlas I see a number of points that perhaps need > further thinking before I sit down and try to generate more tables. The main > point is that we need to decide what the limitations of the tz database should > be. I'd appreciate your advice on the following points, which are roughly in > decreasing order of seriousness. > > There are many, many tables. E.g. France has 153 tables; most of the variants > occurred during World War II, as the fortunes of war caused different > districts to switch between French and German time zone rules. Do we really > want a directory labeled `France' with 153 files in it, one per district? > Even coming up with the district names will be a chore, as Shanks merely gives > each table a number and, for each city, tells you which time table it uses. > > Even the number of countries would mean that the timezone database would be > very bushy at top level, with entries ranging from Afghanistan to Zimbabwe. > Perhaps some substructure is in order. At some point you mentioned using ISO > country codes? (But how many people know their country code?) > > The current code makes no provision for when a district changed from LMT to > standard time (e.g. 1914 Jan 1 in Albania). Strictly speaking, it's incorrect > to give times other than LMT before the switch. At least we should put in a > comment when LMT began, I suppose. But should there be some provision in the > code as well? I suppose it would be something like a suffix to the TZ value > which specifies the LMT offset when LMT is in effect, since you can't possibly > have a table for each LMT offset. > > I doubt whether the following points are worth worrying about in the code, > but perhaps there should be a commenting convention for documenting these > points. > > Some countries switched from the Gregorian to the Julian calendar in this > century; e.g. part of Bulgaria held out until 1920 Sept 17 (Gregorian). I > suppose this is too much for the TZ code to handle, but perhaps comments are > in order. > > The Soviet Union instituted a 5 day week in 1929, a 6 day week in 1932, and > reverted to a 7 day week in 1940. > > China changed from the Chinese calendar on 1912 Feb 12 (Gregorian); > Japan from the Japanese calendar on 1893 Jan 1 (Gregorian). > > There was a time before LMT, when people used apparent time, not mean time. > E.g. Paris switched from apparent time to LMT in 1816.

1 0

Re: Shank's International Atlas, with GB-Eire as a test case
by ado Oct. 15, 1993

Oct. 15, 1993

Paul Eggert's changes are now incorporated in the files tzcode93f.tar.Z and tzdata93f.tar.Z in the ~ftp/pub directory of elsie.nci.nih.gov (128.231.16.1). Thanks to Paul Eggert for the information! --ado

1 0