- tz - lists.iana.org

POSIX conformance for file-based date(1)
by ado Aug. 22, 1989

Aug. 22, 1989

The 1989 version of the file-based "date" command is missing the 'c' in the argument to getopt that's needed to enable its POSIX-conformant handling of a command-line 'c' option. The needed change is attached. --ado *** 7.1/date.c Mon Aug 21 21:26:46 1989 --- 7.2/date.c Mon Aug 21 21:26:48 1989 *************** *** 2,4 **** #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.1"; /* --- 2,4 ---- #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.2"; /* *************** *** 103,105 **** format = value = NULL; ! while ((ch = getopt(argc, argv, "und:t:a:")) != EOF) { switch (ch) { --- 103,105 ---- format = value = NULL; ! while ((ch = getopt(argc, argv, "ucnd:t:a:")) != EOF) { switch (ch) {

1 0

New "europe" file reflecting Peter Ilieve's information
by ado July 18, 1989

July 18, 1989

# @(#)europe 7.2 # International country codes are used to identify countries' rules and # zones # # This data is by no means authoritative; if you think you know better, go # ahead and edit the file (and please send any changes to # ado(a)ncifcrf.gov for general use in the future). ############################################################################### # United Kingdom # From Peter Ilieve (peter(a)memex.co.uk) (July 4, 1989) # # From the UK Government paper "Summer Time: A Consultation Document" # (HMSO Cm722 June 1989), which is about the possibility of the UK moving # into the central European timezone and synchronising its summer time with # the rest of Europe (by moving the end date back a month to end Sep., # the start dates are already the same). # # Summer time was not observed before 1916. # It was introduced in the First World War in response to its introduction # by Germany in March 1916. # During the Second World War normal summer time was used in Winter and double # summer time was used in Summer. # Between 1968 and 1971 GMT+1 was used all year as an experiment. # This caused voluble objections in Scotland and the experiment was judged # a failure. # # Although it does not say what happens in Europe, it does say that most # of Europe did not use summer time until 1979, presumably dropping it # after the 1st and/or 2nd war. # # Note that this is not necessarily accurate for Eire. # # The paper gives a complete record of dates from 1916, and dates up to 1992. # The intention is to have the new system, if any, start in 1993. # The dates are (copied exactly from the table in the paper): # # Summer Time Double Summer Time # Year Start End Start End # 1916 21 May 1 October # 1917 8 April 17 September # 1918 24 March 30 September # 1919 30 March 29 September # 1920 28 March 25 October # (extended from # 27 Sep. because # of coal strike) # # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September # 1924 30 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # # 1939 16 April 19 November # 1940 25 February continued # 1941 continued continued 4 May 10 August # 1942 continued continued 5 April 9 August # 1943 continued continued 4 April 15 August # 1944 continued continued 2 April 17 September # 1945 continued 7 October 2 April 15 July # # 1946 14 April 6 October # 1947 16 March 2 November 13 April 10 August # 1948 14 March 31 October # 1949 3 April 30 October # 1950 16 April 22 October # 1951 15 April 21 October # 1952 20 April 26 October # # 1953 19 April 4 October # 1954 11 April 3 October # 1955 17 April 2 October # 1956 15 April 7 October # 1957 14 April 6 October # 1958 20 April 5 October # 1959 19 April 4 October # 1960 10 April 2 October # # 1961 26 March 29 October # 1962 25 March 28 October # 1963 31 March 27 October # 1964 22 March 25 October # 1965 21 March 24 October # 1966 20 March 23 October # 1967 19 March 29 October # # 1968 18 February continued # 1969 continued continued # 1970 continued continued # 1971 continued 31 October # 1972 19 March 29 October # 1973 18 March 28 October # 1974 17 March 27 October # # 1975 16 March 26 October # 1976 21 March 24 October # 1977 20 March 23 October # 1978 19 March 29 October # 1979 18 March 28 October # 1980 16 March 26 October # 1981 29 March 25 October # # 1982 28 March 24 October # 1983 27 March 23 October # 1984 25 March 28 October # 1985 31 March 27 October # 1986 30 March 26 October # 1987 29 March 25 October # 1988 27 March 23 October # # 1989 26 March 29 October # 1990 25 March 28 October # 1991 31 March 27 October # 1992 29 March 25 October # # These dates agree with the ones from Whitaker's Almanac for 1960--87. . . # From Arthur David Olson (January 19, 1989): # # A source at the British Information Office in New York avers that it's # known as "British" Summer Time in all parts of the United Kingdom. # From an Anonymous U. K. Donor (January 4, 1989): # # It is NOT possible to predict when [British Summer Time] will change # in a future year. # # (The admiralty calculate when they think it should be (no more that a couple # of years in advance) and advise the government who then decide whether or # not they will take the admiralty's advice) # # ...the Gre[e]nwich...observatory...[was] very helpful. # # I was not able to track down the Admiralty formula (I tried hard but failed) # ... # Date: 4 Jan 89 08:57:25 GMT (Wed) # From: Jonathan Leffler <nih-csl!uunet!mcvax!sphinx.co.uk!john> # ... # [British Summer Time] is fixed annually by Act of Parliament. # If you can predict what Parliament will do, you should be in # politics making a fortune, not computing. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular Rule GB-Eire 1916 only - Mar 21 1:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 1:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 1:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 1:00s 0 GMT Rule GB-Eire 1918 only - Mar 24 1:00s 1:00 BST Rule GB-Eire 1918 only - Sep 30 1:00s 0 GMT Rule GB-Eire 1919 only - Mar 30 1:00s 1:00 BST Rule GB-Eire 1919 only - Sep 29 1:00s 0 GMT Rule GB-Eire 1920 only - Mar 28 1:00s 1:00 BST Rule GB-Eire 1920 only - Oct 25 1:00s 0 GMT Rule GB-Eire 1921 only - Apr 3 1:00s 1:00 BST Rule GB-Eire 1921 only - Oct 3 1:00s 0 GMT Rule GB-Eire 1922 only - Mar 26 1:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 1:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 1:00s 1:00 BST Rule GB-Eire 1923 only - Oct 16 1:00s 0 GMT Rule GB-Eire 1924 only - Apr 30 1:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 1:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 1:00s 1:00 BST Rule GB-Eire 1925 1938 - Oct Sun>=1 1:00s 0 GMT # 1939 end to 1947--irregular, and with double summer time Rule GB-Eire 1939 only - Nov 19 1:00s 0 GMT Rule GB-Eire 1940 only - Feb 25 1:00s 1:00 BST Rule GB-Eire 1941 only - May 4 1:00s 2:00 DST Rule GB-Eire 1941 only - Aug 10 1:00s 1:00 BST Rule GB-Eire 1942 only - Apr 5 1:00s 2:00 DST Rule GB-Eire 1942 only - Aug 9 1:00s 1:00 BST Rule GB-Eire 1943 only - Apr 4 1:00s 2:00 DST Rule GB-Eire 1943 only - Aug 15 1:00s 1:00 BST Rule GB-Eire 1944 only - Apr 2 1:00s 2:00 DST Rule GB-Eire 1944 only - Sep 17 1:00s 1:00 BST # Double daylight starts on a Monday in 1945? Rule GB-Eire 1945 only - Apr 2 1:00s 2:00 DST Rule GB-Eire 1945 only - Jul 15 1:00s 1:00 BST Rule GB-Eire 1945 only - Oct 7 1:00s 0 GMT Rule GB-Eire 1946 only - Apr 14 1:00s 1:00 BST Rule GB-Eire 1946 only - Oct 6 1:00s 0 GMT Rule GB-Eire 1947 only - Mar 16 1:00s 1:00 BST Rule GB-Eire 1947 only - Apr 13 1:00s 2:00 DST Rule GB-Eire 1947 only - Aug 10 1:00s 1:00 BST Rule GB-Eire 1947 only - Nov 2 1:00s 0 GMT # So much for double saving time. 1948 and 1949, irregular. Rule GB-Eire 1948 only - Mar 14 1:00s 1:00 BST Rule GB-Eire 1948 only - Oct 31 1:00s 0 GMT Rule GB-Eire 1949 only - Apr 3 1:00s 1:00 BST Rule GB-Eire 1949 only - Oct 30 1:00s 0 GMT # 1950 through start of 1953, regular. Rule GB-Eire 1950 1953 - Apr Sun>=14 1:00s 1:00 BST Rule GB-Eire 1950 1952 - Oct Sun>=21 1:00s 0 GMT # 1954 to 1980, starting rules Rule GB-Eire 1954 only - Apr 11 1:00s 1:00 BST Rule GB-Eire 1955 1959 - Apr Sun>=14 1:00s 1:00 BST Rule GB-Eire 1960 only - Apr 10 1:00s 1:00 BST Rule GB-Eire 1961 1963 - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1964 1967 - Mar Sun>=19 1:00s 1:00 BST Rule GB-Eire 1968 only - Feb 18 1:00s 1:00 BST Rule GB-Eire 1972 1980 - Mar Sun>=16 1:00s 1:00 BST # 1953 to 1971, ending rules Rule GB-Eire 1953 1960 - Oct Sun>=1 1:00s 0 GMT Rule GB-Eire 1961 1967 - Oct Sun>=23 1:00s 0 GMT Rule GB-Eire 1971 only - Oct 31 1:00s 0 GMT # Current rules Rule GB-Eire 1981 max - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1972 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone GB-Eire 0:00 GB-Eire %s 1968 Oct 27 1:00s 1:00 - BST 1971 Oct 31 1:00s 0:00 GB-Eire %s ############################################################################### # Continental Europe # The use of 1986 as starting years below is conservative. Rule W-Eur 1986 max - Mar lastSun 1:00s 1:00 " DST" Rule W-Eur 1986 max - Sep lastSun 1:00s 0 - Rule M-Eur 1986 max - Mar lastSun 2:00s 1:00 " DST" Rule M-Eur 1986 max - Sep lastSun 2:00s 0 - Rule E-Eur 1986 max - Mar lastSun 3:00s 1:00 " DST" Rule E-Eur 1986 max - Sep lastSun 3:00s 0 - Rule Turkey 1986 max - Mar lastSun 1:00 1:00 " DST" Rule Turkey 1986 max - Sep lastSun 1:00 0 - Rule W-SU 1986 max - Mar lastSun 2:00s 1:00 " DST" Rule W-SU 1986 max - Sep lastSun 2:00s 0 - # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone WET 0:00 W-Eur WET%s Zone Iceland 0:00 - WET Zone MET 1:00 M-Eur MET%s Zone Poland 1:00 W-Eur MET%s Zone EET 2:00 E-Eur EET%s Zone Turkey 3:00 Turkey EET%s Zone W-SU 3:00 M-Eur ???? # Tom Hoffman says that MET is also known as Central European Time Link MET CET ############################################################################### # One source shows that Bulgaria, Cyprus, Finland, and Greece observe DST from # the last Sunday in March to the last Sunday in September in 1986. # The source shows Romania changing a day later than everybody else. # # According to Bernard Sieloff's source, Poland is in the MET time zone but # uses the WE DST rules. The Western USSR uses EET+1 and ME DST rules. # Bernard Sieloff's source claims Romania switches on the same day, but at # 00:00 standard time (i.e., 01:00 DST). It also claims that Turkey # switches on the same day, but switches on at 01:00 standard time # and off at 00:00 standard time (i.e., 01:00 DST) # ... # Date: Wed, 28 Jan 87 16:56:27 -0100 # From: seismo!mcvax!cgcha!wtho (Tom Hofmann) # Message-Id: <8701281556.AA22174(a)cgcha.uucp> # ... # # ...the European time rules are...standardized since 1981, when # most European coun[tr]ies started DST. Before that year, only # a few countries (UK, France, Italy) had DST, each according # to own national rules. In 1981, however, DST started on # 'Apr firstSun', and not on 'Mar lastSun' as in the following # years... # But also since 1981 there are some more national exceptions # than listed in 'europe': Switzerland, for example, joined DST # one year later, Denmark ended DST on 'Oct 1' instead of 'Sep # lastSun' in 1981---I don't know how they handle now. # # Finally, DST ist always from 'Apr 1' to 'Oct 1' in the # Soviet Union (as far as I know). # # Tom Hofmann, Scientific Computer Center, CIBA-GEIGY AG, # 4002 Basle, Switzerland # UUCP: ...!mcvax!cernvax!cgcha!wtho # ... # Date: Wed, 4 Feb 87 22:35:22 +0100 # From: seismo!mcvax!cwi.nl!dik (Dik T. Winter) # ... # # The information from Tom Hofmann is (as far as I know) not entirely correct. # After a request from chongo at amdahl I tried to retrieve all information # about DST in Europe. I was able to find all from about 1969. # # ...standardization on DST in Europe started in about 1977 with switches on # first Sunday in April and last Sunday in September... # In 1981 UK joined Europe insofar that # the starting day for both shifted to last Sunday in March. And from 1982 # the whole of Europe used DST, with switch dates April 1 and October 1 in # the Sov[i]et Union. In 1985 the SU reverted to standard Europe[a]n switch # dates... # # It should also be remembered that time-zones are not constants; e.g. # Portugal switched in 1976 from MET (or CET) to WET with DST... # Note also that though there were rules for switch dates not # all countries abided to these dates, and many individual deviations # occurred, though not since 1982 I believe. Another note: it is always # assumed that DST is 1 hour ahead of normal time, this need not be the # case; at least in the Netherlands there have been times when DST was 2 hours # in advance of normal time. # # ... # dik t. winter, cwi, amsterdam, nederland # INTERNET : dik(a)cwi.nl # BITNET/EARN: dik@mcvax # From Bob Devine (January 28, 1988): # ... # Greece: Last Sunday in April to last Sunday in September (iffy on dates). # Since 1978. Change at midnight. # ... # Monaco: has same DST as France. # ...

1 0

British summer time dates from the horse's mouth
by ado July 17, 1989

July 17, 1989

Here's a note I received last week, quoted with permission. A new "europe" file should follow shortly, reflecting at least the 1990, 1991, and 1992 information. --ado > From ncifcrf!@NSFnet-Relay.AC.UK:@cs.heriot-watt.ac.uk:peter@memex.co.uk Thu Jul 13 09:48:05 1989 > Return-Path: <ncifcrf!@NSFnet-Relay.AC.UK:@cs.heriot-watt.ac.uk:peter@memex.co.uk> > Received: from ncifcrf.UUCP by elsie (4.0/SMI-4.0) > id AA09957; Thu, 13 Jul 89 09:48:03 EDT > Received: from NSFnet-Relay.AC.UK by fcs280s.ncifcrf.gov (4.0/NCIFCRF-1.0) > id AA25601; Thu, 13 Jul 89 04:54:06 EDT > Received: from cs.heriot-watt.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP > id aa01688; 13 Jul 89 9:17 BST > Received: by doc.memex.co.uk (5.54/memex_12) > id AA20380; Tue, 4 Jul 89 10:30:35 BST > Date: Tue, 4 Jul 89 10:30:35 BST > From: Peter Ilieve <ncifcrf!NSFnet-Relay.AC.UK!peter%memex.co.uk> > Message-Id: <8907040930.AA20380(a)doc.memex.co.uk> > To: fcs280s!ado > Subject: British summer time dates from the horse's mouth > Status: RO > > >From the UK Government paper "Summer Time: A Consultation Document" > (HMSO Cm722 June 1989), which is about the possibility of the UK moving > into the central European timezone and synchronising its summer time with > the rest of Europe (by moving the end date back a month to end Sep., > the start dates are already the same). > > Summer time was not observed before 1916. > It was introduced in the First World War in response to its introduction > by Germany in March 1916. > During the Second World War normal summer time was used in Winter and double > summer time was used in Summer. > Between 1968 and 1971 GMT+1 was used all year as an experiment. > This caused voluble objections in Scotland and the experiment was judged > a failure. > > Although it does not say what happens in Europe, it does say that most > of Europe did not use summer time until 1979, presumably dropping it > after the 1st and/or 2nd war. > > Note that this is not necessarily accurate for Eire. > > The paper gives a complete record of dates from 1916, and dates up to 1992. > The intention is to have the new system, if any, start in 1993. > The dates are (copied exactly from the table in the paper): > > Summer Time Double Summer Time > Year Start End Start End > 1916 21 May 1 October > 1917 8 April 17 September > 1918 24 March 30 September > 1919 30 March 29 September > 1920 28 March 25 October > (extended from > 27 Sep. because > of coal strike) > > 1921 3 April 3 October > 1922 26 March 8 October > 1923 22 April 16 September > 1924 30 April 21 September > 1925 to 3rd Sunday 1st Sunday > 1938 in April in October > > 1939 16 April 19 November > 1940 25 February continued > 1941 continued continued 4 May 10 August > 1942 continued continued 5 April 9 August > 1943 continued continued 4 April 15 August > 1944 continued continued 2 April 17 September > 1945 continued 7 October 2 April 15 July > > 1946 14 April 6 October > 1947 16 March 2 November 13 April 10 August > 1948 14 March 31 October > 1949 3 April 30 October > 1950 16 April 22 October > 1951 15 April 21 October > 1952 20 April 26 October > > 1953 19 April 4 October > 1954 11 April 3 October > 1955 17 April 2 October > 1956 15 April 7 October > 1957 14 April 6 October > 1958 20 April 5 October > 1959 19 April 4 October > 1960 10 April 2 October > > 1961 26 March 29 October > 1962 25 March 28 October > 1963 31 March 27 October > 1964 22 March 25 October > 1965 21 March 24 October > 1966 20 March 23 October > 1967 19 March 29 October > > 1968 18 February continued > 1969 continued continued > 1970 continued continued > 1971 continued 31 October > 1972 19 March 29 October > 1973 18 March 28 October > 1974 17 March 27 October > > 1975 16 March 26 October > 1976 21 March 24 October > 1977 20 March 23 October > 1978 19 March 29 October > 1979 18 March 28 October > 1980 16 March 26 October > 1981 29 March 25 October > > 1982 28 March 24 October > 1983 27 March 23 October > 1984 25 March 28 October > 1985 31 March 27 October > 1986 30 March 26 October > 1987 29 March 25 October > 1988 27 March 23 October > > 1989 26 March 29 October > 1990 25 March 28 October > 1991 31 March 27 October > 1992 29 March 25 October > > These dates agree with the ones from Whitaker's Almanac for 1960--87 > you quoted in your latest posting of the tzone stuff. > > If we do go into the CET zone then you will have one less thing to worry > about in future. > > Peter Ilieve peter(a)memex.co.uk > >

1 0

Re: machine independence
by Arthur David Olson April 20, 1989

April 20, 1989

> So do you remember how the rest of us (Elz, me, Bob Device, Bradley White, > etc.) got involved? I don't, but the computer does. (One advantage of working on image processing is big disks and lots of tapes.) There was a fair amount of mod.std.unix posting in early '86, kicked off by Mark Horton's original "How best to handle time conversion?" posting. Bob Devine responded since he'd been responsible for time stuff with an earlier employer; he was person who knew that astrologers had the best information about DST in the past. Robert Elz was motivated by the fact that the Australian government fiddled the DST rules down there for a visit by the Queen in March of '86. He boldly installed the early code just before the visit. Robert's changes to "date" to work with the new functions showed up in mod.sources in June of '86. Robert knew of your work before I did: > From munnari!kre Tue Aug 26 13:10:08 1986 remote from seismo > . . . > To: elsie!ado > . . . > Did Guy Harris (sun!guy) ever send you his mods to this stuff? > He has made the compiled timezone files be in "standard" format > so they can reside on one host on a net, and have others access > them (by NFS or whatever), regardless of whether there's a mixture > of Sun's vaxen, etc, with different byte orders & such. Clearly the mods had been sent by the time that the "timezone mailing list" was announced in late '86: > From ado Mon Nov 24 19:58:54 1986 > . . . > To: tz > Subject: seismo!elsie!tz ; new versions of time zone stuff > > Now that we've moved from 4.1BSD to 4.3BSD here at elsie, > I've set things up so that mail sent to > seismo!elsie!tz > will go to folks who've expressed an interest in time zone matters. . . > Currently on the list: > ado(a)elsie.UUCP > chris(a)umcp-cs.UUCP > mark(a)cbosgd.ATT.COM > kre(a)munnari.OZ > dlm(a)cuuxb.ATT.COM > devine(a)vianet.UUCP > bob(a)anvil.UUCP > rgt(a)hpfcdg.UUCP > guy(a)sun.UUCP > . . . > And now the real news: new versions of the time zone compiler, the > ctime et al. library, and the time zone data are available. Guy Harris > provided the bulk of the ideas and work that went into the new versions, > but should be held innocent of any blame for errors since I've tinkered > with Guy's work (in part to try for more compatibility with System V and > the work of rgt(a)hpfcdg.UUCP, who's the time zone person at Hewlett-Packard). > . . . (How it is that I forgot after then how to spell compatibility is beyond me.) The mailing list saw a flurry of activity in December of '86, with an upcoming P1003 meeting due to try to figure out how to standardize time conversion; H-P was preparing an alternative proposal to "P.55," which was based on the table-driven stuff. As part of the flurry, John S. Quarterman (who carried the banner before P1003) got involved at kre's behest: > From seismo!munnari!kre Sun Dec 7 06:57:42 1986 > . . . > To: elsie!tz > Cc: jsq(a)sally.utexas.edu > Subject: timezone proposals for P1003 > . . . > I think things are getting way too complicated. > > All P1003 needs (and all it should have) is a spec of > the interface that programs should have to time conversions. > . . . > Robert Elz seismo!munnari!kre > > ps: I have added a cc to John Quarterman, who I guess is > as close as anyone to being my representative on P1003, > given that I'm a usenix member... John, this is in response > to some discussions over the HP proposals and other replated > issues. elsie!ado can fill you in on what's been going on I think. > There's a mailing list at elsie for tz discussions. Bradley White first appears (at least in my back mail files) in early '87: (presumably after the P1003 meeting?); he was referred by. . . > From seismo!sun!guy Thu Feb 19 06:56:54 1987 > ... > To: elsie!ado > Subject: Could you send him the latest version when it's ready? > Cc: bww(a)k.cs.cmu.edu > Status: RO > > > From: Bradley White <bww(a)k.cs.cmu.edu> > > Subject: Re: diffs for ctime.c for new DST rules, v7 systems > > To: guy(a)Sun.COM > > > Guy, > > > If you could send me (or point me at) a copy of Arthur Olson's "ctime" > > I will have it installed in CMU Mach/Unix. Hopefully this will aid in > > its dissemination. > ... --ado

1 0

Re: machine independence
by Arthur David Olson April 20, 1989

April 20, 1989

> Speaking of "the original ... work", how did this all get started, > anyway? The ultimate impetus was the legislation that changed the start of U. S. Daylight Saving Time from the last Sunday in April to the first Sunday in April. The proximate impetus was a mod.std.unix discussion on the subject. I've attached some of the early electronic mail. By 1/11/86 the format looked much as it does today. The "hard part" not dealt with in the 1/13/86 "distribution" was the text-format-to-binary-format converter (today's zic). --ado > From ado Mon Jan 6 10:28:48 1986 > To: cbosgd!mark > Subject: Daylight Savings Time > Cc: seismo!philabs!linus!encore!necis!geo > Status: O > > Well, I'll admit that my first reaction to the idea of something on the order > of "/etc/dstcap" was a smiley face. But over the weekend I thought about the > matter some more. The result of the thinking was a sheet of paper with this > on it: > > > eastern:\ > > :st=EST:\ > > :dt=EDT:\ > > :os=-21000:\ > ... > Now regardless of the way the above information is encoded, the questions are: > Is there enough information present above to deal with the various > Daylight Saving Time schemes that currently exist? Would the information be > enough to deal with anything that US (or foreign) legislators are likely > to dream up? Or does one *really* need to have something on the order of > "/etc/dstinfo" (with a stack and arithmetic and such)? > > --ado > >From cbosgd!cbpavo.cbosgd.ATT.UUCP!mark Fri Jan 10 16:19:08 1986 remote from seismo > Received: from cbosgd.UUCP by seismo.CSS.GOV with UUCP; Fri, 10 Jan 86 16:05:29 EST > Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) > by cbosgd.ATT.UUCP (4.12/UUCP-Project/11.09.85) > id AA17523; Fri, 10 Jan 86 15:04:29 est > Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) > id AA03218; Fri, 10 Jan 86 15:04:20 est > Date: Fri, 10 Jan 86 15:04:20 est > From: seismo!cbpavo.cbosgd.ATT.UUCP!mark (Mark Horton) > Message-Id: <8601102004.AA03218(a)cbpavo.cbosgd.ATT.UUCP> > To: elsie!ado, harvard!encore!encore!necis!geo > Subject: Re: Daylight Savings Time > > While I like your semantics, the format is horrible. I'd much > prefer to see each year (or year range) in one place rather > than have it scattered over 14 different days of the week. > The format has to be something the average non-guru can understand. > Termcap is a bit much for such people. Something easy like > > Year Key Parm Time GMT offset > 1970 3-sun 4 0200 -0400 > 1970 3-sun 10 0200 -0500 > 1971 3-sun 4 0200 -0400 > 1971 3-sun 10 0200 -0500 > 1972 3-sun 4 0200 -0400 > 1972 3-sun 10 0200 -0500 > 1973 3-sun 4 0200 -0400 > 1973 3-sun 10 0200 -0500 > 1974 julian 120 0200 -0400 > 1974 julian 306 0200 -0500 > 1975 julian 0 0200 -0400 > 1975 julian 366 0200 -0500 > 1976 3-sun 4 0200 -0400 > 1976 3-sun 10 0200 -0500 > > This could probably be translated into a handy binary format for ctime > to use quickly. The parm is either the month number (for things like > "3rd Sunday") or the Julian date on which to make the change. The > above numbers are probably all wrong but you get the idea. You could > have any number of changes in a year, although 2 would be common. > > Mark > From ado Sat Jan 11 12:42:16 1986 > To: cbosgd!mark > Subject: DST > Status: O > > An alternate approach to allow for multiple time zones. Make the rules look > like: > > Rule Year(s) Month Day Time ST offset String > MostUS -1973 Apr last-Sun 2:00 1:00 D > MostUS -1973 Oct last-Sun 2:00 0 S > MostUS 1974 Jan last-Sun 2:00 1:00 D > MostUS 1974 Nov last-Sun 2:00 0 S > MostUS 1975 Feb last-Sun 2:00 1:00 D > MostUS 1975 Oct last-Sun 2:00 0 S > MostUS 1976- Apr last-Sun 2:00 1:00 D > MostUS 1976- Oct last-Sun 2:00 0 S > Patron 1969- Apr last-Sun 2:00 1:00 D > Patron 1969- Jul last-Sun 2:00 2:00 DD > Patron 1969- Aug last-Sun 2:00 1:00 D > Patron 1969- Oct last-Sun 2:00 0 S > > and the Time Zone information look like > > Name GMT offset Rule Abbreviation > Eastern -5:00 MostUS E%sT > Central -6:00 MostUS C%sT > Pacific -8:00 MostUS P%sT > Alaskan ? MostUS A%sT > Hawaiian ? MostUS H%sT > Patronian ? Patron P%sT > > --ado > From ado Mon Jan 13 21:04:01 1986 > To: cbosgd!mark > Subject: The easy part of ctime() > Status: O > > The next letter from me should be a shell archive containing five files: > Makefile > timezone.h > ctime.c > try.c > fake.c > The important files are "timezone.h" which gives the format of "binary time > zone information files," and "ctime.c" which makes use of the files. . . ==============================================================

1 0

Re: leap seconds
by ado June 9, 1988

June 9, 1988

> After some phone calls to NBS and Naval Observatory, I found out > that there have been 14 leap seconds inserted. > > 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 > ... > 14) 1987 Dec 31 23:59:60 # Naval Observatory Which, providentially, agrees with the data in the comp.sources.unix posting. Hats off to bww and guy! --ado

1 0

Re: leap seconds
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 9, 1988

June 9, 1988

> The phase 'my clock is 14 seconds slow' has been used recently and is > one off from the 15 leap seconds listed above or the 17 leap seconds > which would have been added had Bob's statement been correct. After some phone calls to NBS and Naval Observatory, I found out that there have been 14 leap seconds inserted. 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 2) 1972 Dec 31 23:59:60 # NBS Special Publication #432 3) 1973 Dec 31 23:59:60 # NBS Special Publication #432 4) 1974 Dec 31 23:59:60 # NBS Special Publication #432 5) 1975 Dec 31 23:59:60 # NBS Special Publication #432 6) 1976 Dec 31 23:59:60 # NBS Special Publication #432 7) 1977 Dec 31 23:59:60 # NBS Special Publication #432 8) 1978 Dec 31 23:59:60 # NBS Special Publication #432 9) 1979 Dec 31 23:59:60 # Naval Observatory 10) 1981 Jun 30 23:59:60 # Naval Observatory 11) 1982 Jun 30 23:59:60 # Naval Observatory 12) 1983 Jun 30 23:59:60 # Naval Observatory 13) 1985 Jun 30 23:59:60 # Naval Observatory 14) 1987 Dec 31 23:59:60 # Naval Observatory The earth has been slowing down so there won't be a yearly insertion as there was in the 70s. Next leap second is anticipated to be in added in 1 1/2 or 2 years. Bob [ David Hoerl, could you send me mail directly? I can't reply to you using the address I got -- ...!decwrl.dec!cookie.dec.com!devine ]

1 0

Leap seconds
by Ronald G. Tolley June 6, 1988

June 6, 1988

>> 1973 June 30 23:59:60 >> 1973 June 30 23:59:61 > > Positive leap seconds were inserted in all NBS broadcasts > at the end of June 30, 1972 and December 31, 1972 thru 1978. > > [ All years since 1978 have had leap seconds. Bob] A AP article out of Washington written in about May 1985 states that "that [adding leap seconds] was done twice in 1972 and once every year since except 1980 and 1984." The same article stated that the 1985 leap second would be the last second in June. >From the data which has gone around recently including the comment above, I have constructed the following list of leap seconds: 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 2) 1972 Dec 31 23:59:60 # NBS Special Publication #432 3) 1973 Dec 31 23:59:60 # NBS Special Publication #432 4) 1974 Dec 31 23:59:60 # NBS Special Publication #432 5) 1975 Dec 31 23:59:60 # NBS Special Publication #432 6) 1976 Dec 31 23:59:60 # NBS Special Publication #432 7) 1977 Dec 31 23:59:60 # NBS Special Publication #432 8) 1978 Dec 31 23:59:60 # NBS Special Publication #432 9) 1979 Dec 31 23:59:60 # June or December? # AP Article no leap second in 1980 10) 1981 Dec 31 23:59:60 # June or December? 11) 1982 Dec 31 23:59:60 # June or December? 12) 1983 Dec 31 23:59:60 # June or December? # AP Article no leap second in 1984 13) 1985 Jun 30 23:59:60 # AP Article 14) 1986 Dec 31 23:59:60 # June or December? 15) 1987 Dec 31 23:59:60 # June or December? Is there a more complete or more correct list available? (All this fuss over a handful of seconds!) The phase 'my clock is 14 seconds slow' has been used recently and is one off from the 15 leap seconds listed above or the 17 leap seconds which would have been added had Bob's statement been correct. Ron Tolley

1 0

leap seconds; [0-60] is ok
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 2, 1988

June 2, 1988

> When the first leap seconds were added, which I believe were in 1973, > there were two inserted at the same time. Thus a single legal value has > had the seconds denoted as "61". From memory, these two leap seconds > were: > > 1973 June 30 23:59:60 > 1973 June 30 23:59:61 No, only one second is ever added at a time. However, Ron is right about the first year (1972) containing two leap seconds. Below is the relevant section describing how leap seconds are inserted/deleted. Bob Devine [ On a sidenote to time, the Herstmonceux Castle where the Greenwich Observatory is located is for sale. You can buy it for only ~$15M.] From the NBS Special Publication #432 (issued in 1979): When leap second adjustments are necessary to keep the broadcast time signals (UTC) within +/- 0.9 second of the earth-related UT1 time scale, the addition or deletion of exactly 1 second occurs at the end of the UTC month. By international agreement, first preference is given to December 31 or June 30, second preference to March 31 or September 30, and third preference to any other month. When a positive leap second is required -- that is, when UT1 is slow relative to UTC -- an additional second is inserted beginning 23h 59m 60s of the last day of the month and ending at 0h 0m 0s of the first day of the following month. In this case the last minute of the month in which there is a leap second contains 61 seconds. Assuming that unexpected large changes do not occur in the earth's rotation rate in the future, it is likely that positive leap seconds will continue to be needed about once per year. If, however, the earth should speed up significantly at some future time, so that UT1 runs at a _faster_ rate than UTC, then provision is also made for negative leap seconds in the UTC time scale. In this case, exactly one second would be deleted at the end of some UTC month, and the last minute would contain only 59 seconds. Positive leap seconds were inserted in all NBS broadcasts at the end of June 30, 1972 and December 31, 1972 thru 1978. [ All years since 1978 have had leap seconds. Bob]

1 0

Re: Time conversion and second public... [forwarded from rgt@hpfcrg]
by ado June 2, 1988

June 2, 1988

> * The range of seconds has been changed from "[0-59]" to "[0-60]" > throughout, to allow for leap seconds. Whether this is a good > thing or not depends on what you think POSIX wants. When the first leap seconds were added, which I believe were in 1973, there were two inserted at the same time. Thus a single legal value has had the seconds denoted as "61". From memory, these two leap seconds were: 1973 June 30 23:59:60 1973 June 30 23:59:61 All other leap seconds, as I recall, have been added singly so other than the single second noted above "[0-60]" would be sufficient. However if we are to do a complete job, let's handle this "61" too. Ron Tolley

1 0

Time conversion and second public review of draft proposed ANSI C
by ado June 1, 1988

June 1, 1988

I've yet to receive the draft proposed standard that's the subject of the third public review period; I have, though, received "X3J11 Response ot Issues Raised by Miscellaneous Public Comments (Not an official X3J11 document)." Here's what the "Response" has to say on time conversion matters: * The range of seconds has been changed from "[0-59]" to "[0-60]" throughout, to allow for leap seconds. Whether this is a good thing or not depends on what you think POSIX wants. * The Committee declined to change the phrase "time zone name" to "time zone name abbreviation". Some vendors will be surprised when they learn that "strftime" is supposed to fill structures with pointers to strings such as "mountain standard time" (which is a time zone name) rather than to strings such as "MST" (which is a time zone name abbreviation). Reading the Committee's response, I'm inclined to believe that I failed to clearly draw the distinction, and that a clearer explanation, along with a modified suggestion that the phrase be changed to "time zone name or abbreviation," might be more positively received. * The Committee declined to move the contents of footnote 109 into the Standard proper. In my letter to the Committee, I said: Footnote 109 reads Thus, a positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time. The described behavior of mktime when tm_isdst is negative cannot be deduced from the Standard proper; given Section 4.12.1's words that "The value of tm_isdst is. . .negative if the information is not available," an implementer of mktime could reasonably say "No information about DST is available, so we won't try to account for it." Proposed Change Move the text of footnote 109 into the Standard proper, changing "Thus, a positive. . ." to "A positive. . ." The "Response" indicates that the Committee believes the behavior described in footnote 109 represents the only reasonable interpretation of the standard. Looks as if the vendors will be able to take the easy way out (described above), and as if user's won't be able to rely on the "tm_isdst == -1" mechanism to get DST accounted for. -- "Only external identifiers and macro names described in the Standard as reserved shall be reserved" must go in. This is non-negotiable. ado(a)ncifcrf.gov ADO is a trademark of Ampex.

1 0

time representation
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 1, 1988

June 1, 1988

Bradley White says: > Just as an aside, UNIX time_t values are not an appropriate representation > of time in a distributed system. An ASCII rendition of UT is much better. To continue the aside: The appropriate ISO standards for representing date and time are: ISO 4031, ISO 3307, and ISO 2014. Send me mail if you want some functions that convert time_t to/from a subset of those ISO standards. Bob Devine

1 0

Re: tz package
by cvl!uts.amdahl.com!cvl!chongo May 31, 1988

May 31, 1988

>> I suggest that you put a BIG warning around the use of 'leapseconds' >> in time calculations. For a number of reasons, POSIX (IEEE standard >> Unix, soon to be ANSI and ISO standard unix) prohibits the standard >> conversion to/from "Seconds since the Epoch" functions from taking >> leapseconds into account. > >I think we came to the conclusion before doing the leapsecond stuff that >the wording in POSIX *requires* that standard conversion routines take >leapseconds into account. Just to be sure we have communicated... POSIX really does state that "seconds since the Epoch" explicitly excludes leap seconds in the calculation. Since all current POSIX time conversion functions and time_t timestamps derive their value from "seconds since the Epoch", no POSIX function can make use of leapseconds. This is not to say that a later draft could not add NEW functions that do take leap seconds into account. But since P1003.1 is NOW in FINAL BALLOT, it will be a long time before such a standard function would show up. The impact of adding leapseconds as you have done can be more than a simply 'my clock is 14 seconds slow'. Networks of systems or multi-os systems or multi-cpu systems could have a different time_t value for the current time. These systems could convert the same time_t value into a different string. Make can get messed up, transaction time stamps can be wrong, etc... That is why I suggested that you point a big warning about not using leapseconds. No system using them can ever be POSIX (or SVID since it will conform to POSIX) and no system as shipped by a major (or minor?) computer builder uses them. Is patch level 1 your current patch? chongo <> /\oo/\

2 2

Re: tz package
by ado May 30, 1988

May 30, 1988

> I started looking over your tz package. Thin[g]s look nice. Have you had > any patches since the posting? My Patchlevel.h file shows I am at > PATCHLEVEL #1. No "released to a source moderator" patches yet, and nothing that's very big. I've attached some "unofficial" diffs to the end of this letter: Makefile the suggestion to remove "timezone.o" from "libc.a" is deleted tzfile.h a redundant definition of TM_SUNDAY is deleted getopt.c is now the latest version from Berkeley (with an elsie header on the front to keep sccs happy) localtime.c has an added workaround for a bug in 3B1s. The 3B1 workaround is the change I'm least sure of; after I made it I sent it off to the person who originally reported the problem and asked for a blessing; I've yet to receive a response. In particular I'm not sure that conditioning on "m68k" is right; this may just be a 3B1 problem. A bit back Guy Harris sent along changes to allow localtime to handle POSIX-style TZ environment variables; as soon as I confirm that it's okay to do so, I can send these along. > I suggest that you put a BIG warning around the use of 'leapseconds' > in time calculations. For a number of reasons, POSIX (IEEE standard > Unix, soon to be ANSI and ISO standard unix) prohibits the standard > conversion to/from "Seconds since the Epoch" functions from taking > leapseconds into account. This means that if anyone does use the > timezone deltas, their system will be out of conformance. If leapseconds > are desired, then such systems need to use different time conversion > functions to do this. If you could work up a "chapter and verse" explanation, I'd be glad to add it to the distribution. Presumably the thing to do would be to have LEAPSECONDS default to /dev/null in the Makefile, with a note in the Makefile on how to get leapseconds accounted for and an explanation of why you might not want to. --ado *** 4.1/Makefile Mon May 30 12:26:20 1988 --- 4.2/Makefile Mon May 30 12:26:33 1988 *************** *** 1,4 **** ! # @(#)Makefile 4.1 # If you want something other than Eastern United States time used on your # system, change the line below (after finding the zone you want in the --- 1,4 ---- ! # @(#)Makefile 4.2 # If you want something other than Eastern United States time used on your # system, change the line below (after finding the zone you want in the *************** *** 14,20 **** # You may want to change this define if you're just testing the software. # Alternatively, you can put these functions in /lib/libc.a, removing ! # the old "ctime.o" (and "timezone.o" on a BSD system). This is the # ideal solution if you are able. Build libz.a, extract the files, and # then add them to libc.a. --- 14,20 ---- # You may want to change this define if you're just testing the software. # Alternatively, you can put these functions in /lib/libc.a, removing ! # the old "ctime.o". This is the # ideal solution if you are able. Build libz.a, extract the files, and # then add them to libc.a. *** 4.1/getopt.c Mon May 30 12:27:21 1988 --- 4.2/getopt.c Mon May 30 12:27:22 1988 *************** *** 1,16 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)getopt.c 4.1"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ ! #include "string.h" ! #ifndef strchr ! #define index strchr ! #endif /* !defined strchr */ #include <stdio.h> --- 1,28 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)getopt.c 4.2"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ ! /* ! * Copyright (c) 1987 Regents of the University of California. ! * All rights reserved. ! * ! * Redistribution and use in source and binary forms are permitted ! * provided that this notice is preserved and that due credit is given ! * to the University of California at Berkeley. The name of the University ! * may not be used to endorse or promote products derived from this ! * software without specific written prior permission. This software ! * is provided ``as is'' without express or implied warranty. ! */ ! #ifdef LIBC_SCCS ! #ifndef lint ! static char sccsid[] = "@(#)getopt.c 4.5 (Berkeley) 11/24/87"; ! #endif /* !defined lint */ ! #endif /* defined LIBC_SCCS */ #include <stdio.h> *************** *** 17,23 **** /* * get option letter from argument vector */ ! int opterr = 1, /* useless, never set or used */ optind = 1, /* index into parent argv vector */ optopt; /* character checked for validity */ char *optarg; /* argument associated with option */ --- 29,35 ---- /* * get option letter from argument vector */ ! int opterr = 1, /* if error message should be printed */ optind = 1, /* index into parent argv vector */ optopt; /* character checked for validity */ char *optarg; /* argument associated with option */ *************** *** 24,65 **** #define BADCH (int)'?' #define EMSG "" ! #define tell(s) fputs(*nargv,stderr);fputs(s,stderr); \ ! fputc(optopt,stderr);fputc('\n',stderr);return(BADCH); ! getopt(nargc,nargv,ostr) ! int nargc; ! char **nargv, ! *ostr; { ! static char *place = EMSG; /* option letter processing */ ! register char *oli; /* option letter list index */ char *index(); ! if(!*place) { /* update scanning pointer */ ! if(optind >= nargc || *(place = nargv[optind]) != '-' || !*++place) return(EOF); ! if (*place == '-') { /* found "--" */ ++optind; return(EOF); } ! } /* option letter okay? */ ! if ((optopt = (int)*place++) == (int)':' || !(oli = index(ostr,optopt))) { ! if(!*place) ++optind; tell(": illegal option -- "); } ! if (*++oli != ':') { /* don't need argument */ optarg = NULL; ! if (!*place) ++optind; } ! else { /* need an argument */ ! if (*place) optarg = place; /* no white space */ else if (nargc <= ++optind) { /* no arg */ place = EMSG; tell(": option requires an argument -- "); } ! else optarg = nargv[optind]; /* white space */ place = EMSG; ++optind; } ! return(optopt); /* dump back option letter */ } --- 36,90 ---- #define BADCH (int)'?' #define EMSG "" ! #define tell(s) { \ ! if (opterr) { \ ! fputs(*nargv, stderr); \ ! fputs(s, stderr); \ ! fputc(optopt, stderr); \ ! fputc((int)'\n', stderr); \ ! } \ ! return(BADCH); \ ! } ! getopt(nargc, nargv, ostr) ! int nargc; ! char **nargv, *ostr; { ! static char *place = EMSG; /* option letter processing */ ! register char *oli; /* option letter list index */ char *index(); ! if (!*place) { /* update scanning pointer */ ! if (optind >= nargc || *(place = nargv[optind]) != '-' || ! !*++place) ! return(EOF); ! if (*place == '-') { /* found "--" */ ++optind; return(EOF); } ! } /* option letter okay? */ ! if ((optopt = (int)*place++) == (int)':' || ! !(oli = index(ostr, optopt))) { ! if (!*place) ! ++optind; tell(": illegal option -- "); } ! if (*++oli != ':') { /* don't need argument */ optarg = NULL; ! if (!*place) ! ++optind; } ! else { /* need an argument */ ! if (*place) /* no white space */ ! optarg = place; else if (nargc <= ++optind) { /* no arg */ place = EMSG; tell(": option requires an argument -- "); } ! else /* white space */ ! optarg = nargv[optind]; place = EMSG; ++optind; } ! return(optopt); /* dump back option letter */ } *** 4.1/tzfile.h Mon May 30 12:25:44 1988 --- 4.2/tzfile.h Mon May 30 12:25:49 1988 *************** *** 2,8 **** #ifndef NOID #ifndef TZFILE_H #define TZFILE_H ! static char tzfilehid[] = "@(#)tzfile.h 4.1"; #endif /* !defined TZFILE_H */ #endif /* !defined NOID */ #endif /* !defined lint */ --- 2,8 ---- #ifndef NOID #ifndef TZFILE_H #define TZFILE_H ! static char tzfilehid[] = "@(#)tzfile.h 4.2"; #endif /* !defined TZFILE_H */ #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 107,113 **** #define TM_OCTOBER 9 #define TM_NOVEMBER 10 #define TM_DECEMBER 11 - #define TM_SUNDAY 0 #define TM_YEAR_BASE 1900 --- 107,112 ---- *** 4.1/localtime.c Mon May 30 12:49:30 1988 --- 4.6/localtime.c Mon May 30 12:49:47 1988 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 4.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 4.6"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 389,394 **** --- 389,403 ---- } days = *clock / SECSPERDAY; rem = *clock % SECSPERDAY; + #ifdef mc68k + if (*clock == 0x80000000) { + /* + ** A 3B1 muffs the division on the most negative number. + */ + days = -24855; + rem = -11648; + } + #endif /* mc68k */ rem += (offset - corr); while (rem < 0) { rem += SECSPERDAY;

1 0

tz package
by mcf!umix!ames!uts.amdahl.com!chongo May 30, 1988

May 30, 1988

I started looking over your tz package. Thinks look nice. Have you had any patches since the posting? My Patchlevel.h file shows I am at PATCHLEVEL #1. I suggest that you put a BIG warning around the use of 'leapseconds' in time calculations. For a number of reasons, POSIX (IEEE standard Unix, soon to be ANSI and ISO standard unix) prohibits the standard conversion to/from "Seconds since the Epoch" functions from taking leapseconds into account. This means that if anyone does use the timezone deltas, their system will be out of conformance. If leapseconds are desired, then such systems need to use different time conversion functions to do this. chongo <> /\oo/\

2 1

More converts?
by ado May 2, 1988

May 2, 1988

> Path: elsie!cvl!umd5!purdue!decwrl!labrea!rutgers!bellcore!tness7!ninja!sys1!sneaky!trsvax!uhclem > From: uhclem(a)trsvax.UUCP > Newsgroups: comp.sys.tandy > Subject: Re: Time on Tandy 3.2 > Message-ID: <193300057@trsvax> > Date: 25 Apr 88 15:43:00 GMT > References: <1618(a)scicom.alphacdc.com> > Lines: 66 > Nf-ID: #R:scicom.alphacdc.com:1618:trsvax:193300057:000:3009 > Nf-From: trsvax.UUCP!uhclem Apr 25 10:43:00 1988 ... > In XENIX 3.2, the routines that manage date conversions now examine a > file for the rules on how to handle DST. So if the U.S. government > changes the fall date (which is expected), or makes any other change, > a change to the rule-file will fix handling for all programs. This also > works nice if you happen to live in a country that is 15 minutes + solar time > or some other unusual local time convention. ... > Frank Durda IV > @ <trsvax!uhclem> > ...decvax!microsoft!trsvax!uhclem > ...convex!infoswx!hal6000!trsvax!uhclem I'm trying to find out if "the file" mentioned above is really the comp.sources.unix files. -- ado(a)ncifcrf.gov ADO is a trademark of Ampex.

1 0

Re: Interested in time.
by cvl!mimsy!uunet!Sun.COM!guy April 26, 1988

April 26, 1988

I recently looked at your excellent time package. However, it appeared to me that if someone in a foreign country got a copy of a machine with this code, that they would have a hard problem figuring out what TZ to use, as they are not enumerated in ctime.3 (at least in my copy), nor did there appear to be any tools to build such a file from the /etc/zoneinfo directory. My question is thus: have you developed a program that walks the directories, and builds a table of the available entries? The way we intend to solve this for SunOS 4.0 is to give a listing of the various TZ values, and the areas to which particular values apply, in the "installing SunOS" documentation.

1 0

Interested in time.
by DF Hoerl April 24, 1988

April 24, 1988

I recently looked at your excellent time package. However, it appeared to me that if someone in a foreign country got a copy of a machine with this code, that they would have a hard problem figuring out what TZ to use, as they are not enumerated in ctime.3 (at least in my copy), nor did there appear to be any tools to build such a file from the /etc/zoneinfo directory. My question is thus: have you developed a program that walks the directories, and builds a table of the available entries? David Hoerl, AT&T Bell Labs PS: would you add me to the list of people interested in time? Thanks.

1 0

Time zone stuff
by suns!chase%orc.olivetti.com April 20, 1988

April 20, 1988

Is the time zone package which you provide in the public or "free" domain? If so, I wish to make use of it in the library for another language (Modula-3, but it is glued to an ANSI library). Thanks much, David Chase Olivetti Research Center, Menlo Park

1 0

Problem with new PD localtime
by cvl!mimsy!uunet!datapg.MN.ORG!sewilco April 8, 1988

April 8, 1988

Have any problems been reported with 'localtime' on a 3B1 (System V). Something seems to be wrong with my copy of 'zic'. All of the USA entries with daylight savings time are zeroed. For example, 'od -c CST6CDT' is: 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000054 Also, "zdump" reports all those times with a "GMT" label. Any suggestions? I had the same problem with the previous version and waited for the new one. Further details: I got errors of bad leapsecond values, so changed localtime to /dev/null. Changes in Makefile: LOCALTIME= US/Central TZDIR= /usr/local/zoneinfo LEAPSECONDS= /dev/null CFLAGS= -DSTD_INSPIRED -DUSG_COMPAT -DUSG # test -f /usr/bin/ranlib && ranlib $@ Changes to pacificnew: # Following four lines due to no PPET yet #Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE #Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S #Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S Rule Twilite 1987 max - Oct lastSun 2:00 0 S Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX consulting +1 612-825-2607 uunet!datapg!sewilco

1 0

Problems with new PD localtime
by suns!sewilco%datapg.mn.org April 8, 1988

April 8, 1988

Have any problems been reported with 'localtime' on a 3B1 (System V). Something seems to be wrong with my copy of 'zic'. All of the USA entries with daylight savings time are zeroed. For example, 'od -c CST6CDT' is: 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000054 Also, "zdump" reports all those times with a "GMT" label. Any suggestions? I had the same problem with the previous version and waited for the new one. Further details: I got errors of bad leapsecond values, so changed localtime to /dev/null. Changes in Makefile: LOCALTIME= US/Central TZDIR= /usr/local/zoneinfo LEAPSECONDS= /dev/null CFLAGS= -DSTD_INSPIRED -DUSG_COMPAT -DUSG # test -f /usr/bin/ranlib && ranlib $@ Changes to pacificnew: # Following four lines due to no PPET yet #Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE #Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S #Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S Rule Twilite 1987 max - Oct lastSun 2:00 0 S Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX consulting +1 612-825-2607 uunet!datapg!sewilco

1 0

Re: PD Localtime changes since v08i085?
by ado March 14, 1988

March 14, 1988

I've sent an updated version of the time conversion package to rsalz(a)uunet.uu.net; with providence it should appear in comp.sources.unix shortly. --ado

1 0

PD Localtime changes since v08i085?
by emoryu1!gatech!rutgers!datapg.mn.org!sewilco March 14, 1988

March 14, 1988

Were there any changes to the PD "localtime" since the version posted in mod.sources as v08i085 on 28 Feb 87? It's time to use it, and I need to know if there were bugs found. I don't see any updates in the archive listings. The only change which I found so far was changing the "pacificnew" entries from type "uspres" and "nonpres" to a single type "-" entry. According to the Department of Transportation, no version of the Presidential Election Time became law. Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress C and UNIX consulting +1 612-825-2607

1 0

time zone functions in January 11, 1988 draft C standard
by ado Feb. 17, 1988

Feb. 17, 1988

Little in the way of change to time functions in the January 11, 1988 draft C standard. Recall that the last draft said, in the main text, this about the tm_isdst element of the struct tm structure: The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available. It later described the new "mktime" function for converting a struct tm back into a time_t value, noting in a footnote that A positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time. Your correspondent sent a letter to the X3J11 committee, noting (among other things) that the above material was all well and good, but since it was in a footnote, \fIand since footnotes are not part of the Standard\fP, programmers would not be able to count on the above characteristics of mktime. Well, the good news is that X3J11 acted on this point. The other news is that they simply changed the footnote to read Thus, a positive or zero value for tm_isdst. . . This makes me realize just how feeble-minded I must be getting in my dotage. I didn't understand (and still don't understand) how the promise that "A negative value for tm_isdst causes [mktime] to attempt to determine whether [DST] is in effect. . ." is implied by the description of tm_isdst in the standard. (Actually, I'm unclear about both sentences in the footnote, but the second especially.) Maybe someone on the time zone mailing list will be able to set me clear before I again make a fool of myself in my next letter to the Committee? Other than the added "Thus," there were no time-related changes to section 4.12 of the draft. They did throw in a few "noalias"es and required that if you #include <time.h> then NULL and size_t will be defined for you. --ado

1 0

Help wanted in updating time zone information files
by ado Jan. 2, 1988

Jan. 2, 1988

I'm hoping to send some updated time zone information files to comp.sources.unix soon (as soon as I can learn the equation of time for 1988 and, with that information, do up the 1988 Riyadh table). I've attached a bundle of the new files that would be used in making the posting; I'd appreciate any corrections or additional information that folks might provide. Here's a summary of the changes these files reflect. Thanks to Guy Harris for providing the vast majority of the changes. * The "northamerica" file has information about Mexico and about DST being observed on Navajo lands within Arizona. * The "pacificnew" file has information on the status of H.R. 435 (the bill whose passage would necessitate use of the "pacificnew" stuff). * The "southamerica" file is completely new. * The "asia" file is almost completely new; it now covers both Chinas and the Republic of Korea. --ado : To unbundle, sh this file echo 'northamerica' 1>&2 cat >'northamerica' <<'End of northamerica' # @(#)northamerica 3.4 # US Daylight Saving Time ended on the last Sunday of *October* in 1974. # See, for example, the front page of the Saturday, October 26, 1974 # and Sunday, October 27, 1974 editions of the Washington Post. # Note also this from seismo!munnari!kre: # "I recall also being told by someone once that Canada didn't have # the DST variations in 74/75 that the US did, but I am not nearly # sure enough of this to add anything." # The above has been confirmed by Bob Devine; we'll go with it here. # Before the Uniform Time Act of 1966 took effect in 1967, observance of # Daylight Saving Time in the US was by local option, except during wartime. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 max - Apr Sun>=1 2:00 1:00 D ############################################################################### # New names # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Eastern -5:00 US E%sT Zone US/Central -6:00 US C%sT Zone US/Mountain -7:00 US M%sT Zone US/Pacific -8:00 US P%sT Zone US/Yukon -9:00 US Y%sT # Mainland US areas that are always Standard as of 1986. Zone US/East-Indiana -5:00 US E%sT 1946 -5:00 - EST # Always EST as of 1986 Zone US/Arizona -7:00 US M%sT 1946 -7:00 - MST # Always MST as of 1986 # However. . .a writer from the Inter Tribal Council of Arizona, Inc., # notes in private correspondence dated 12/28/87 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." Link US/Mountain Navajo # And then there's Hawaii. # DST was observed for one day in 1933; # Standard time was change by half an hour in 1947; # it's always standard as of 1986. Zone US/Hawaii -10:30 US H%sT 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 1 2:00 -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Old names, for S5 users # Link LINK-FROM LINK-TO Link US/Eastern EST5EDT Link US/Central CST6CDT Link US/Mountain MST7MDT Link US/Pacific PST8PDT Link US/East-Indiana EST Link US/Arizona MST Link US/Hawaii HST ################################################################################ # Canada is reportedly lots easier than the US--leastways since 1951. # I don't know what they did before then. # 4.3BSD claims that it's perfectly regular. # According to a posting in "comp.bugs.misc", "comp.unix.wizards", etc. # on February 8, 1987, by Dave Sherman of the Law Society of Upper Canada, # "...Canada (well, Ontario and at least some of the other provinces) are # adopting the new daylight savings time rules...". We assume all of # Canada is doing so. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Canada 1969 max - Oct lastSun 2:00 0 S Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D Rule Canada 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] # Bob Devine says that DST *is* observed in Newfoundland Zone Canada/Newfoundland -3:30 Canada N%sT Zone Canada/Atlantic -4:00 Canada A%sT Zone Canada/Eastern -5:00 Canada E%sT Zone Canada/Central -6:00 Canada C%sT Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 Zone Canada/Mountain -7:00 Canada M%sT Zone Canada/Pacific -8:00 Canada P%sT Zone Canada/Yukon -9:00 Canada Y%sT ################################################################################ # Mexico # Rules are from the Official Airline Guide, Worldwide Edition, for 1987. # Rules prior to 1987 are unknown. # The comments in the OAG say "Only Ensenada, Mexicale, San Felipe and Tijuana # observe DST." This is presumably Baja California Norte, above 28th parallel, # as listed there; Mexico/BajaSur is for "Baja California Sur and N. Pacific # Coast (States of Sinaloa and Sonora)." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mexico 1987 max - Oct lastSun 2:00 0 S Rule Mexico 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Mexico/BajaNorte -8:00 Mexico P%sT Zone Mexico/BajaSur -7:00 - MST Zone Mexico/General -6:00 - CST End of northamerica echo 'pacificnew' 1>&2 cat >'pacificnew' <<'End of pacificnew' # @(#)pacificnew 3.4 # The U.S. House of Representatives passed a bill (H.R. 435) establishing # "Pacific Presidential Election Time" on November 10, 1987; # it has yet (as of January 2, 1988) been approved by the U.S. Senate # or signed into law by the U.S. President. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Twilite 1987 max - Apr Sun>=1 2:00 1:00 D Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Pacific-New -8:00 US P%sT 1987 -8:00 Twilite P%sT End of pacificnew echo 'southamerica' 1>&2 cat >'southamerica' <<'End of southamerica' # @(#)southamerica 1.1 # From Official Airline Guide - Worldwide Edition (1987). Countries not # listed here do not observe DST, according to the OAG. Time zone names # are pure inventions, and none are supplied for countries not observing # DST; updates from natives would be appreciated. The times that DST # starts and ends are based on the assumption that they switch a 2AM just # as everybody else does. # Brazil # The OAG lists October 25, 1987 and February 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year". We # infer a rule here from one example, always a dangerous practice.... Yes, # they really do switch on Saturday, according to the OAG. # "Brazil/Acre" is for the Territory of Acre; "Brazil/DeNoronha" is for # Fernando De Noronha. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Brazil 1987 max - Feb Sat<=14 2:00 0 S Rule Brazil 1987 max - Oct Sat<=28 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Brazil/East -3:00 Brazil E%sT Zone Brazil/West -4:00 Brazil W%sT Zone Brazil/Acre -5:00 Brazil A%sT Zone Brazil/DeNoronha -2:00 Brazil F%sT # Chile # The OAG lists October 11, 1987 and March 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1987 max - Mar Sun<=14 2:00 0 S Rule Chile 1987 max - Oct Sun<=14 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Chile/Continental -4:00 Chile C%sT Zone Chile/EasterIsland -6:00 Chile E%sT End of southamerica echo 'asia' 1>&2 cat >'asia' <<'End of asia' # @(#)asia 3.3 # Incorporates data for Singapore from Robert Elz' asia 1.1, as well as # additional information from Tom Yap, Sun Microsystems Intercontinental # Technical Support (including a page from the Official Airline Guide - # Worldwide Edition). The names for time zones are guesses. # People's Republic of China. Yes, they really have only one time zone. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule PRC 1970 max - Apr Sun<=14 2:00 1:00 D Rule PRC 1970 max - Sep Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone PRC 8:00 PRC C%sT # Republic of Korea. According to someone at the Korean Times in San Francisco, # Daylight Savings Time was not observed until 1987. He did not know # at what time of day DST starts or ends. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ROK 1987 max - May Sun<=14 2:00 1:00 D Rule ROK 1987 max - Oct Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone ROK 9:00 - KST 1987 9:00 ROK K%sT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Japan 9:00 - JST Zone Singapore 8:00 - SST Zone Hongkong 8:00 - HKT Zone ROC 8:00 - CST # Israel # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Israel 1987 max - Apr Sun<=21 2:00 1:00 D Rule Israel 1987 max - Aug Sat<=28 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 3:00 Israel I%sT End of asia exit

1 0