- tz - lists.iana.org

australasia zoneinfo
by cvl!cvl!mimsy!uunet!munnari!physiol.su.oz.au!daved March 3, 1990

March 3, 1990

I have just modified our Australasia zoneinfo file to take account of changes in the NSW rule, and have incorporated changes distributed from Queensland and South Australia over the Australian news recently. I have also added code for Lord Howe Island (perhaps not in the most efficient manner possible). Lord Howe maintains GMT+10:30 when the New South Wales mainland is observing GMT+10:00. When the mainland moves to daylight saving time, it adopts the same time, namely GMT+11:00. So its "saving" is only 30 minutes. My complete file follows: # @(#)australasia 4.1+ (daved mods) # Incorporates updates for Australia from Robert Elz' australia 1.1 # and further updates from the Australian consulate. # Australian Data (for states with DST), standard rules # Includes shift in 1987 to follow Vic/NSW rules for ending DST, # and shift in 1986 to start DST earlier. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Oz 1971 1985 - Oct lastSun 2:00 1:00 - Rule Oz 1986 max - Oct Sun<=24 2:00 1:00 - Rule Oz 1972 only - Feb 27 3:00 0 - Rule Oz 1973 1986 - Mar Sun>=1 3:00 0 - Rule Oz 1987 max - Mar Sun<=21 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Tasmania 10:00 Oz EST Zone Australia/North 9:30 - CST # No DST here Zone Australia/West 8:00 - WST # No DST here Zone Australia/South 9:30 SA CST # The government seems to change things by regulation, not by changing the act. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SA 1971 1985 - Oct lastSun 2:00 1:00 - Rule SA 1972 1985 - Mar Sun>=1 3:00 0 - Rule SA 1986 only - Mar 16 3:00 0 - Rule SA 1986 only - Oct 19 2:00 1:00 - Rule SA 1987 only - Mar 15 3:00 0 - Rule SA 1987 max - Oct lastSun 2:00 1:00 - Rule SA 1988 only - Mar 20 3:00 0 - Rule SA 1989 max - Mar Sun<=21 3:00 0 - # Victoria jumped to a later ending date for DST in 1986 rather than 1987. Zone Australia/Victoria 10:00 Oz EST 1985 Oct lastSun 2:00 10:00 1:00 EST 1986 Mar Sun<=21 3:00 10:00 Oz EST # New South Wales and subjurisdictions have their own ideas of a fun time. # Based on law library research by John Mackin (john(a)basser.cs.su.oz) # who notes: # In Australia, time is not legislated federally, but rather by the # individual states. Thus, while such terms as ``Eastern Standard Time'' # [I mean, of course, Australian EST, not any other kind] are in common # use, _they have NO REAL MEANING_, as they are not defined in the # legislation. This is very important to understand. # I have researched New South Wales time only. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NSW 1971 1985 - Oct lastSun 2:00 1:00 - Rule NSW 1972 only - Feb lastSun 3:00 0 - Rule NSW 1973 1981 - Mar Sun>=1 3:00 0 - Rule NSW 1982 only - Apr 4 3:00 0 - Rule NSW 1983 1985 - Mar Sun>=1 3:00 0 - Rule NSW 1986 only - Mar 16 3:00 0 - Rule NSW 1986 only - Oct 19 2:00 1:00 - Rule NSW 1987 only - Mar 15 3:00 0 - Rule NSW 1987 max - Oct lastSun 2:00 1:00 - Rule NSW 1988 only - Mar Sun>=1 3:00 0 - Rule NSW 1989 only - Mar Sun<=21 3:00 0 - Rule NSW 1990 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/NSW 10:00 NSW EST Zone Australia/Broken-Hill 9:00 NSW ??? Zone Australia/Sturt 9:00 NSW ??? Zone Australia/Yancowinna 9:30 NSW ??? # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule LHI 1971 1985 - Oct lastSun 2:00 0:30 - Rule LHI 1972 only - Feb lastSun 3:00 0 - Rule LHI 1973 1981 - Mar Sun>=1 3:00 0 - Rule LHI 1982 only - Apr 4 3:00 0 - Rule LHI 1983 1985 - Mar Sun>=1 3:00 0 - Rule LHI 1986 only - Mar 16 3:00 0 - Rule LHI 1986 only - Oct 19 2:00 0:30 - Rule LHI 1987 only - Mar 15 3:00 0 - Rule LHI 1987 max - Oct lastSun 2:00 0:30 - Rule LHI 1988 only - Mar Sun>=1 3:00 0 - Rule LHI 1989 only - Mar Sun<=21 3:00 0 - Rule LHI 1990 max - Mar Sun>=1 3:00 0 - Zone Australia/LHI 10:30 LHI ??? # Queensland introduced DST for a `trial' period of 1 year # Based on the Daylight Saving Act 1989, No. 78 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule QLD 1989 only - Oct 29 2:00 1:00 - Rule QLD 1990 only - Mar 4 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Queensland 10:00 QLD EST # New Zealand, from Elz' asia 1.1 # Elz says "no guarantees" # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NZ 1974 max - Oct lastSun 2:00 1:00 D Rule NZ 1975 max - Mar Sun>=1 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone NZ 12:00 NZ NZ%sT # New Zealand # # A footnote here: # # . . . # Date: Thu, j19 Feb 87 12:02:17 EST # From: Bradley White <seismo!k.cs.cmu.edu!bww> # . . . # I am including a description of Australian time zones. . . # this stuff is definitely accurate. # . . . # a) Australian Eastern Time: (EST = GMT+10:00, EDT = GMT+11:00) # . . . # Summer of 86/87 - present (current legislation): # third Sun Oct 02:00 EST -> third LSun Mar 02:00 EST # # If this turns out to be true, substitute Sun<=21 (third Sunday in October) # for Sun<=24 (next-to-last Sunday in October) above. . .some time before # October 1988, the first time it makes a difference. #

1 0

Updated leap seconds file
by ado Oct. 15, 1989

Oct. 15, 1989

Word just in is that there'll be a leap second at the end of the year. --ado *** 7.1/leapseconds Sat Oct 14 20:44:25 1989 --- 7.2/leapseconds Sat Oct 14 20:44:26 1989 *************** *** 1,4 **** ! # @(#)leapseconds 7.1 # Allowance for leapseconds added to each timezone file. --- 1,4 ---- ! # @(#)leapseconds 7.2 # Allowance for leapseconds added to each timezone file. *************** *** 26,28 **** --- 26,29 ---- Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S + Leap 1989 Dec 31 23:59:60 + S

1 0

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