- tz - lists.iana.org

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