- tz - lists.iana.org

Updated UK history of Summer Time
by peter＠aldie.co.uk Jan. 6, 1998

Jan. 6, 1998

A few months ago now I received email out of the blue from Joseph Myers <jsm28(a)cam.ac.uk>. He had seen the various things from me in the europe file and asked if I had found any of the missing old Orders, volunteering to help with this. He has an incomparable advantage over me in having ready access to Cambridge University Library and in a matter of days he had turned up most of the old Orders. A few days later and he had all the EC directives as well. I then sat on all this for months as I was too busy to collate it all, but this delay has had one advantage in that I can now include the Summer Time Order 1997, which came into force on 30 December 1997. Our new legislation is now on the web and this Order should appear soon at http://www.hmso.gov.uk/si/si1997/97298201.htm. If there is still room in the file for all this sort of commentary, this mail with the list that follows could usefully replace the emails of mine dated 1994-12-01, 1993-11-18, 1996-05-29, 1993-10-29, 1993-10-28, 1993-10-22, 1993-09-03, 1993-10-18 and 1993-09-03 (what a clearout :-). Peter Ilieve peter(a)aldie.co.uk --- The following list attempts to show the complete history of Summer Time legislation in the United Kingdom, and has quite a bit to say about the Isle of Man and the Channel Islands as well. Things that I have not personally seen are marked (???). The problem with finding old Orders (rather than Acts) is that nobody seems to keep the actual documents themselves, not even the Government. They get bound into annual volumes, which are published, but by the time this happens the Orders are mainly spent as the years they refer to have come and gone, so they don't get included in the annual volumes. Thanks are due to my learned legal friend Lorna Montgomerie, who dug out the dusty old statutes, to Melanie Allison of the Ministry of Defence, who provided the wartime regulations and a snippet of Hansard explaining why double summer time started on a Monday in 1945 (it was Easter), and to Joseph Myers <jsm28(a)cam.ac.uk>, who tracked down the Orders up to 1945 and the first five EC Directives. Some definitions: Great Britain: England, Scotland and Wales United Kingdom: Great Britain plus Ireland (up to 1922) or Northern Ireland (since 1922) SI: Statutory Instrument, the modern name for secondary legislation SR&O: Statutory Rules and Orders, the older name for secondary legislation Unless otherwise specified, Acts and secondary legislation are assumed to apply throughout the United Kingdom, but not to the Isle of Man or the Channel Islands. Some of the Acts and Orders I found in various libraries, and I don't have copies. When I looked at them I was looking for dates and not things like whether they applied to the Bailiwick of Jersey. I will try to check these documents again. --- - The Statutes (Definition of Time) Act, 1880 Defined Greenwich Mean Time to be the standard time in Great Britain and Dublin Mean Time to be the standard time in Ireland, superseding various forms of local mean time. - The Isle of Man (War Legislation) Act, 1914 Gives the power, by Order in Council, to extend wartime legislation to the Isle of Man. - The Summer Time Act, 1916 Introduced Summer Time for the first time, in Great Britain and Ireland. Specified a one hour offset from GMT (DMT in Ireland), dates of Sunday 21 May and Sunday 1 October and times of 02:00 (GMT/DMT). Gave a power to make Orders in subsequent years, for the duration of the then current war. - The Time (Ireland) Act, 1916 This abolished Dublin Mean Time at 02:00 DMT on Sunday 1 October 1916, bringing the whole of the United Kingdom onto GMT. As Ireland was behind GMT/BST at 02:00 DMT on 1 Oct Great Britain have already put the clocks back. Using DST as Dublin Summer Time the sequence would have been: Dublin London 02:34 DST 02:59 BST 02:35 DST 02:00 GMT 02:59 DST 02:24 GMT 02:25 GMT 02:25 GMT with the transition 03:00 DST -> 02:00 DMT -> 02:25 GMT all at once. - SR&O 1916, No 382 An Order made under the the Isle of Man (War Legislation) Act, 1914 extending the the Summer Time Act, 1916 to the Isle of Man. Dated 23 May 1916, two days after the start of Summer Time, but it says that the Act is deemed to have taken effect in the Isle of Man at the same time as it took effect in the United Kingdom. - SR&O 1917, No 362 An Order made under the the Summer Time Act, 1916 giving dates for Summer Time in 1917 of Sunday 8 April to Monday 17 September, both at 02:00 GMT. Note that Summer Time ends on a Monday. - SR&O 1917, No 358 An Order made under the the Summer Time (Isle of Man) Act, 1916 (the thing created by SR&O 1916, No 382) specifying the same dates of 8 April to 17 September, at 02:00 GMT for the Isle of Man. - SR&O 1918, No 274 An Order made under the the Summer Time Act, 1916 giving dates for Summer Time in 1918 of Sunday 24 March to Monday 30 September, both at 02:00 GMT. - SR&O 1918, No 429 The matching Isle of Man Order for 1918 with the same dates and times. - SR&O 1919, No 297 An Order made under the the Summer Time Act, 1916 giving dates for Summer Time in 1919 of Sunday 30 March to Monday 29 September, both at 02:00 GMT. - SR&O 1919, No 366 The matching Isle of Man Order for 1919 with the same dates and times. - SR&O 1920, No 458 An Order made under the the Summer Time Act, 1916 giving dates for Summer Time in 1920 of Sunday 28 March to Monday 27 September, both at 02:00 GMT. - SR&O 1920, No 573 The matching Isle of Man Order for 1920 with the same dates and times. - SR&O 1920, No 1844 An Order modifying both SR&O 1920, No 458 and SR&O 1920, No 573 to change the end date for Summer Time from Monday 27 September to Monday 25 October (the time remaining 02:00 GMT). The 1989 Green Paper (Cm 722) says this was done because of a coal strike. - The War Emergency Laws (Continuance) Act, 1920 (???) This extends the power to make Orders under the the Summer Time Act, 1916 for a period of 12 months after the termination of the war. I haven't seen this one so I don't know when it came into force, or when the law deemed the termination of the war to have been. - SR&O 1921, No 363 An Order made under the the Summer Time Act, 1916 and the War Emergency Laws (Continuance) Act, 1920 giving dates for Summer Time in 1921 of Sunday 3 April to Monday 3 October, both at 02:00 GMT. - SR&O 1921, No 364 The matching Isle of Man Order for 1921 with the same dates and times. - SR&O 1922, No 264 (???) This probably defines Summer Time for 1922 as the Summer Time Act, 1922 was passed after the start date. - SR&O 1922, No 290 (???) This is probably the matching Isle of Man Order. - The Summer Time Act, 1922 This specifies an offset of 1 hour and dates of the day after the third Saturday in April, unless that be Easter, in which case it is the day after the second Saturday, and the day after the third Saturday in September. The time is 02:00 GMT. It applied in 1922 and 1923, and longer if Parliament so approved. It applied to the Isle of Man and the Channel Islands as well. Came into Force on 20 July 1920. Note the reversion to ending on a Sunday. - SR&O 1922, No 1205 An Order made under the The War Emergency Laws (Continuance) Act, 1920 dated 13 October 1922. It revokes (among other things) the Order extending the Summer Time Act, 1916 to the Isle of Man. - The Summer Time Act, 1925 This makes the 1922 Act permanent, with a change to the end date to the day after the first Saturday in October. Came into force on 7 August 1925. As the 1922 Act expired on 31 December 1923 unless Parliament did something about it, there are presumably some missing Orders for 1924 and 1925. - The Emergency Powers (Defence) Act, 1939 (???) I haven't seen this one. It presumably gave the Government powers to do all manner of things during the newly started war. - The Defence (Summer Time) Regulations, 1939, SR&O 1939, No 1379 These were made under the Emergency Powers (Defence) Act, 1939. They change the end date to be the day after the third Saturday in November. - SR&O 1940, No 1883 An Order in Council amending the The Defence (Summer Time) Regulations, 1939. This continues summer time throughout the year after it starts in 1940. There was another Order (SR&O 1940, No 172) that I assume had merely changed the dates, and was then superseded by this one. I haven't seen No 172. - SR&O 1941, No 476 Another Order amending the The Defence (Summer Time) Regulations, 1939. This introduces double summer time, starting at 01:00 GMT on the day after the first Saturday in May and ending at 01:00 GMT on the day after the second Saturday in August, offset another hour from normal summer time, which continues throughout the rest of the year. - SR&O 1942, No 506 Another Order amending the The Defence (Summer Time) Regulations, 1939. This changes the start date of double summer time to the day after the first Saturday in April, bringing it forward from May. - SR&O 1944, No 932 This changed the end date of double summer time to 17 September 1944. (I don't have the text of this, just a note of what it did, the text almost certainly had the `day after the nth Saturday' form.) - SR&O 1945, No 312 (???) Probably defines the dates of Double Summer Time in 1945. I do have this quote from Hansard (the official record of the UK Parliament), Oral Answers, 1 March 1945, cols 1559--60: `58. Major Sir Goronwy Owen asked the Secretary of State for the Home Department if he is now able to state the Government's proposals regarding double summer time. [two other similar questions omitted] Mr. H. Morrison: The Government, in reviewing the matter, have considered, [...] the conclusion has been reached that the adoption of double summer time from the beginning of April is essential to the maintenance of the war effort. [...] As 1st April is Easter Sunday, when very early services are held in many churches, it is proposed that double summer time shall start not in the night preceding Easter Sunday, but in the night of Sunday- Monday so that it will operate from Monday, 2nd April.' - SR&O 1945, No 1208 An Order under the Emergency Powers (Defence) Acts, 1939 and 1940 revoking a long list of things, including the Defence (Summer Time) Regulations, 1939. This meant that Summer Time reverted to being set by the 1922 and 1925 Acts. - The Summer Time Act, 1947 Came into force on 11 March 1947. Amended the Summer Time Acts, 1922 and 1925 to change the dates of Summer Time and to introduce Double Summer Time (although it doesn't give this, or any, name for this period of 2 hour offset from GMT). Dates are given for 1947 only and are: 02:00 GMT Sunday 16 March, 01:00 GMT Sunday 13 April, 01:00 GMT Sunday 10 August, and 02:00 Sunday 2 November. It gave a power to make Orders for subsequent years, both to vary the dates and to continue Double Summer Time. It applied to the Isle of Man and the Channel Islands. - Summer Time Order, 1948 (SI 1948/495) (???) - Summer Time Order, 1949 (SI 1949/373) (???) - Summer Time Order, 1950 (SI 1950/518) (???) - Summer Time Order, 1951 (SI 1951/430) (???) - Summer Time Order, 1952 (SI 1952/451) (???) These presumably give the dates of Summer Time for the relevent years. There was no Double Summer Time. The dates given in the 1989 Green Paper for these years are: 1948: 14 March to 31 October 1949: 3 April to 30 October 1950: 16 April to 22 October 1951: 15 April to 21 October 1952: 20 April to 26 October After 1952 things revert back to the 1922 and 1925 Acts. - The Interpretation Act (Northern Ireland), 1954 (???) I presume that section 39 of this Act is similar to section 9 of the Interpretation Act, 1978 (listed below) in specifying GMT as the legal time in Northern Ireland, replacing the Time (Ireland) Act, 1916. - Summer Time Order, 1961 (SI 1961/71) Specified dates of 26 March and 29 October (02:00 GMT) for 1961 - Summer Time (1962) Order, 1961 (SI 1961/2465) Specified dates of 25 March to 28 October (02:00 GMT) for 1962. - Summer Time Order, 1963 (SI 1963/81) Specified dates of 31 March to 27 October (02:00 GMT) for 1963. - Summer Time (1964) Order, 1963 (SI 1963/2101) Specified dates of 22 March to 25 October (02:00 GMT) for 1964. - Summer Time Order, 1964 (SI 1964/1201) Specified dates for three years (all 02:00 GMT): 1965: 21 March to 24 October 1966: 20 March to 23 October 1967: 19 March to 29 October - Summer Time Order, 1967 (SI 1967/1148) - Summer Time Order, 1968 (SI 1968/117) The first of these specifies dates for 1968 of 18 February for the United Kingdom but 7 April for the Isle of Man, both ending on 27 October, all at 02:00 GMT. The second Order changes the Isle of Man start date to 18 February to match the UK. - The British Standard Time Act, 1968 This came into force on 27 October 1968 and continued summer time throughout the year. It expired at 02:00 GMT on 31 October 1971, as specified in the Act, as Parliament did not move to make this experment permanent. It applied to the Isle of Man and the Channel Islands. Interestingly, it says baldly `This Act shall come into force on 27 October 1968', without giving a time. As S1 of the Act merely stated that `The time for general purposes in the United Kingdom (to be known as British standard time) shall be one hour in advance of Greenwich mean time throughout the year; ...' you could possibly argue that the start time of BStandardT was 00:00 1968-10-27, especially as the Act repealed the Summer Time Acts 1916--1947 in toto, thereby destroying the authority of the Summer Time Order specifying summer time in 1968. - The Manx Time Act, 1968 This is an Act of Tynwald (the Isle of Man Parliament) that said that henceforth Manx time would be the same as the time in Great Britain. - The Summer Time Act, 1972 This specified a reversion to normal Summer Time behaviour with a start date of the day after the third Saturday in March, unless that is Easter, when it is the day after the second Saturday, and an end date of the day after the fourth Saturday in October. Times are at 02:00 GMT, offset is 1 hour. It gives the power to make Orders to vary these dates and times. This Act is still in force and is the legal authority for implementing the EC Directives in the UK. - The Interpretation Act, 1978 Section 9 of this Act replaces section 1 of the Statutes (Definition of Time) Act, 1880 with very similar wording maintaining GMT as the legal time in Great Britain. This does not apply in Northern Ireland (it has its own Interpretation Act listed above). - Council Directive of 22 July 1980 on summertime arrangements (80/737/EEC) The first of the European Directives on Summer Time. It specified start dates for 1981 and 1982. No agreement had been reached on end dates. Only dates were given, there was no rule like `last Sunday in March'. The main change for the United Kingdom was a move to a 01:00 GMT change time. The dates: 1981: 29 March 1982: 28 March - Summer Time Order, 1980 (SI 1980/1089) Specified dates for 1981 and 1982, with the start dates as in the EC Directive: 1981: 29 March to 25 October 1982: 28 March to 24 October - Second Council Directive of 10 June 1982 on summertime arrangements (82/399/EEC) The next European Directive. Specified dates for three years, 1983 to 1985. Agreement still hadn't been reached on a common end date, and wouldn't be until 1994 with the appeareance of the seventh Directive with a common date for 1996 and beyond, but this time the Directive gave two sets of end dates. The start date was specified by rule: the last Sunday in March. All times were 01:00 GMT. The end dates were given without rule, as: 1983: 25 September or 23 October 1984: 30 September or 28 october 1985: 29 September or 27 October - Summer Time Order, 1982 (SI 1982/1673) Implemented the second EC Directive, using the October end dates. 1983: 27 March to 23 October 1984: 25 March to 28 october 1985: 31 March to 27 October - Third Council Directive of 12 December 1984 on summertime arrangements (84/634/EEC) Specified start dates of the last Sunday in March and two sets of end dates, last Sunday in September and fourth Sunday in October, all at 01:00 GMT. The end dates were also specified as dates: 1986: 28 September or 26 October 1987: 27 September or 25 October 1988: 25 September or 23 October - Summer Time Order, 1986 (SI 1986/223) Implemented the third EC Directive, using the October end dates. 1986: 30 Match to 26 October 1987: 29 March to 25 October 1988: 27 March to 23 October - Council Directive of 20 December 1985 amending Directive 84/634/EEC on summertime arrangements (85/582/EEC) This was to do with the accession of Spain and Portugal to the EEC. The previous directve had used wording like `Member States belonging to the zero (Greenwich) time zone' when refering to the different sets of end dates. Portugal was in that time zone but was not going to follow the UK and Ireland dates, so the text was reworded without any change to the dates themselves. - Fourth Council Directive of 22 December 1987 on summertime arrangements (88/14/EEC) This Directive covered only a single year: 1989. My guess is that this was because 1989 was one of the years when the historic UK end date of the Sunday after the fourth Saturday in October differed from the rule in the previous Directive of the fourth Sunday in October. All times are 01:00 GMT. No rule was specified, specific dates were given: 1989: 26 March to 24 September or 29 October - Summer Time Order, 1988 (SI 1988/931) Implemented the dates of 26 March to 29 October for 1989. - Fifth Council Directive of 21 December 1988 on summertime arrangements (89/47/EEC) Covered the three years 1990 to 1992. All times are 01:00 GMT. Gave both rules (last Sunday in March, last Sunday in September or fourth Sunday in October) and specific dates: 1990: 25 March to 30 September or 28 October 1991: 31 March to 29 September or 27 October 1992: 29 March to 27 September or 25 October - Summer Time Order, 1989 (SI 1989/985) Implemented the fifth Directive using the October end dates. - Sixth Council Directive 92/20/EEC of 26 March 1992 on summertime arrangements Covered the two years 1993 and 1994. All times are 01:00 GMT. Specified both rules (same as the fifth Directive) and specific dates: 1993: 28 March to 26 September or 24 October 1994: 27 March to 25 September or 23 October - Summer Time Order, 1992 (SI 1992/1729) Implemented the sixth Directive using the October end dates. - Seventh Directive 94/21/EC of the European Parliament and of the Council of 30 May 1994 on summer-time arrangements Covered the three years 1995 to 1997. Agreement had finally been reached on a common end date, to start in 1996. Both rules and dates were given. The rules were the same last Sunday in March to last Sunday in September or fourth Sunday in October for 1995, with the end rule changing to the last Sunday in October for 1996 and 1997. The year 1995 was another of the tricky ones where the EC and traditional UK rules differed but this time the UK changed on the fourth Sunday, 22 October, earlier than usual. All times are 01:00 GMT. Specific dates were also given: 1995: 26 March to 24 September or 22 October 1996: 31 March to 27 October 1997: 30 March to 26 October - Summer Time Order 1994 (SI 1994/2798) Implements the seventh Directive using the October end date in 1995. Applies also to the Bailiwick of Guernsey but not to the Bailiwick of Jersey or the Isle of Man, which have their own (unspecified) legislation on the subject. - Eighth Directive 97/44/EC of the European Parliament and of the Council of 22 July 1997 on summer-time arrangements Covers four years: 1998 to 2001. All times are 01:00 GMT. Specifies both rules, last Sunday in March and ast Sunday in October, and specific dates: 1998: 29 March to 25 October 1999: 28 March to 31 October 2000: 26 March to 29 October 2001: 25 March to 28 October - Summer Time Order 1997 (SI 1997/2982) Implements the eighth Directive. Has the same text about the Isle of Man, Guernsey and Jersey as the 1994 Order.

4 4

Australian time legislation
by Eric Ulevik Jan. 5, 1998

Jan. 5, 1998

Here are some URLs to Australian time legislation. These URLs are stable, and should probably be included in the data file. There are probably more relevant entries in this database. NSW (including LHI and Broken Hill): http://www.austlii.edu.au/au/legis/nsw/consol_act/sta1987137/index.html ACT http://www.austlii.edu.au/au/legis/act/consol_act/consol_act/stasta1972279/i ndex.html SA http://www.austlii.edu.au/au/legis/sa/consol_act/sta1898137/index.html Regards, Eric Ulevik

1 0

Israel Timezone -- Tentative Dates for 1998
by Ephraim Silverberg Dec. 31, 1997

Dec. 31, 1997

Here are the tentative (subject to final parliamentary approval) dates for the State of Israel for the year 1998. The following are context diffs for the file 'asia' extracted from ftp://elsie.nci.nih.gov/pub/tzdata1997k.tar.gz -----------------------------Begin Context Diff------------------------------ *** asia.orig Mon Dec 29 16:53:41 1997 --- asia Wed Dec 31 13:24:50 1997 *************** *** 547,562 **** # The dates for 1996 were determined by the Minister of Interior of the # time, Haim Ramon. The official announcement regarding 1996-1998 ! # (with the dates for 1997 no longer being relevant) can be viewed at: # # ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # ! # The dates for 1997 were altered by his successor, Rabbi Eli Suissa. ! # No changes have been made regarding 1998 as of yet. ! # # The official announcement for the year 1997 can be viewed at: # # ftp://ftp.huji.ac.il/pub/tz/announcements/1997.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Mar 15 0:00 1:00 D --- 547,564 ---- # The dates for 1996 were determined by the Minister of Interior of the # time, Haim Ramon. The official announcement regarding 1996-1998 ! # (with the dates for 1997-1998 no longer being relevant) can be viewed at: # # ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # ! # The dates for 1997-1998 were altered by his successor, Rabbi Eli Suissa. # The official announcement for the year 1997 can be viewed at: # # ftp://ftp.huji.ac.il/pub/tz/announcements/1997.ps.gz + # + # According to the Office of the Spokeswoman for the Ministry of Interior, + # the dates for 1998 are tentative and are still subject to final approval + # (probably in late February/early March of 1998). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Mar 15 0:00 1:00 D *************** *** 564,570 **** Rule Zion 1997 only - Mar 21 0:00 1:00 D Rule Zion 1997 only - Sep 14 0:00 0 S Rule Zion 1998 only - Mar 20 0:00 1:00 D ! Rule Zion 1998 only - Oct 18 0:00 0 S # From Paul Eggert (1997-03-15): # Here are guesses for rules after 1998. --- 566,572 ---- Rule Zion 1997 only - Mar 21 0:00 1:00 D Rule Zion 1997 only - Sep 14 0:00 0 S Rule Zion 1998 only - Mar 20 0:00 1:00 D ! Rule Zion 1998 only - Sep 6 0:00 0 S # From Paul Eggert (1997-03-15): # Here are guesses for rules after 1998. ------------------------------End Context Diff------------------------------- If there are any changes or when final approval is obtained, I'll inform the 'tz' list. ___________________________________________________________________________ Ephraim Silverberg, CS System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-6585439 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cs.huji.ac.il

1 0

tzcode1997i.tar.gz and tzdata1997k.tar.gz
by ado Dec. 29, 1997

Dec. 29, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997i.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997k.tar.gz are now available. These incorporate the changes circulated on the time zone list by Paul Eggert, with minor modifications from Arthur David Olson to make the files more browser friendly. --ado

1 0

proposed tz patch for UTC vs GMT, France through 1976, etc.
by Paul Eggert Dec. 27, 1997

Dec. 27, 1997

Here is a set of proposed patches to the tz database to cover the following issues: * As Denis.Excoffier(a)ens.fr pointed out, descriptions are a bit sloppy about the distinction between GMT, UT, and UTC. GMT was the official time base until the 1920s, when the term UT took over; UTC is a UT variant that became codified as the basis for civil time around 1960. The proposed patch attempts to use the correct terms more consistently. * Excoffier also pointed out that some of the data for France between 1916 and 1976 did not agree with the Ephemerides Astronomiques, and the effective dates of the French Revolutionary calendar were incorrect in the comments. * msb(a)sq.com reported that Atikokan, Ontario did not observe DST, but we don't have the details, so for now we'll just include a comment about it. * Europe/Ljubljana, Europe/Sarajevo, Europe/Skopje, and Europe/Zagreb are more efficiently maintained as links to Europe/Belgrade, since they've been identical ever since standard time was introduced. * Sun no longer does the equivalent of defining TM_GMTOFF in their recent releases, but Linux does. * A thread-safe tz file reader is now available as part of the GNU C Library. * The DHL time zone database is no longer easily reachable. * The Gregorian calendar was introduced gradually in Switzerland. =================================================================== RCS file: RCS/Makefile,v retrieving revision 1997.8 retrieving revision 1997.8.0.1 diff -u -r1997.8 -r1997.8.0.1 --- Makefile 1997/12/11 17:50:04 1997.8 +++ Makefile 1997/12/27 07:53:14 1997.8.0.1 @@ -17,7 +17,7 @@ # time zone files, or adding it to a time zone file). # (When a POSIX-style environment variable is handled, the rules in the # template file are used to determine "spring forward" and "fall back" days and -# times; the environment variable itself specifies GMT offsets of standard and +# times; the environment variable itself specifies UTC offsets of standard and # summer time.) # Alternately, if you discover you've got the wrong time zone, you can just # zic -p rightzone @@ -122,7 +122,7 @@ # to the end of the "CFLAGS=" line. # Neither tm_gmtoff nor _tm_gmtoff is described in X3J11's work; # in its work, use of "tm_gmtoff" is described as non-conforming. -# Both UCB and Sun have done the equivalent of defining TM_GMTOFF in +# Both Linux and BSD have done the equivalent of defining TM_GMTOFF in # their recent releases. # # If your system has a "zone abbreviation" field in its "struct tm"s @@ -150,7 +150,7 @@ # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". # "timegm" is like "timelocal" except that it turns a struct tm into -# a time_t using GMT (rather than local time as "timelocal" does). +# a time_t using UTC (rather than local time as "timelocal" does). # "timeoff" is like "timegm" except that it accepts a second (long) argument # that gives an offset to use when converting to a time_t. # "posix2time" and "time2posix" are described in an included manual page. =================================================================== RCS file: RCS/Theory,v retrieving revision 1997.7 retrieving revision 1997.7.0.1 diff -u -r1997.7 -r1997.7.0.1 --- Theory 1997/09/04 20:54:15 1997.7 +++ Theory 1997/12/27 07:53:14 1997.7.0.1 @@ -71,7 +71,7 @@ system's best idea of local wall clock. (This is important for applications that an administrator wants used only at certain times-- without regard to whether the user has fiddled the "TZ" environment - variable. While an administrator can "do everything in GMT" to get + variable. While an administrator can "do everything in UTC" to get around the problem, doing so is inconvenient and precludes handling daylight saving time shifts--as might be required to limit phone calls to off-peak hours.) @@ -157,7 +157,7 @@ but this functionality was removed in later versions of BSD. * In SVR2, time conversion fails for near-minimum or near-maximum - time_t values when doing conversions for places that don't use GMT. + time_t values when doing conversions for places that don't use UTC. This package takes care to do these conversions correctly. The functions that are conditionally compiled if STD_INSPIRED is defined @@ -281,5 +281,5 @@ Application writers should note that these abbreviations are ambiguous in practice: e.g. `EST' has a different meaning in Australia than it does in the United States. In new applications, it's often better -to use numeric GMT offsets like `-0500' instead of time zone +to use numeric UTC offsets like `-0500' instead of time zone abbreviations like `EST'; this avoids the ambiguity. =================================================================== RCS file: RCS/WWW.htm,v retrieving revision 1997.6 retrieving revision 1997.6.0.1 diff -u -r1997.6 -r1997.6.0.1 --- WWW.htm 1997/07/18 04:03:20 1997.6 +++ WWW.htm 1997/12/27 07:53:14 1997.6.0.1 @@ -20,7 +20,7 @@ to UTC offsets and daylight-saving rules. This database (often called <samp>zoneinfo</samp>) is used by several implementations, -including BSD, DJGPP, GNU/Linux, Irix, Solaris, and Unixware. +including BSD, DJGPP, GNU/Linux, HP-UX, IRIX, Solaris, and UnixWare. In the tz database's <A HREF="ftp://elsie.nci.nih.gov/pub/">FTP distribution</A>, the code is in the file <samp>tzcode<var>C</var>.tar.gz</samp>, @@ -28,6 +28,12 @@ similarly, the data are in <samp>tzdata<var>D</var>.tar.gz</samp>, where <samp><var>D</var></samp> is the data's version. <P> +The <A HREF="ftp://ftp.gnu.org/pub/gnu/GETTING.GNU.SOFTWARE"> +GNU C Library</A> has an independent, thread-safe implementation of +a time zone file reader. +This library is freely available under the GNU Library General Public License, +and is widely used in GNU/Linux systems. +<P> The Web has several other sources for time zone and daylight saving time data. Here are some recent links that may be of interest. <UL> @@ -62,7 +68,7 @@ with diagrams. The time zone map is out of date, however. <LI><A HREF="http://community.bellcore.com/mbr/gmt-explained.html">A Few Facts -Concerning RGO, GMT, and UT, by Richard B. Langley</A> +Concerning GMT, UT, and the RGO</A> answers questions like ``What is the difference between GMT and UTC?'' <LI><A HREF="http://www.energy.ca.gov/energy/daylightsaving.html">Daylight Saving Time -- Saving Time, Saving Energy</A> @@ -79,7 +85,7 @@ when leap seconds occur. </UL> -- <A HREF="mailto:eggert@twinsun.com">eggert(a)twinsun.com</A> -(1997-07-16) +(1997-12-26) </P> <H2>Arthur David Olson writes:</H2><P> A good source of information about ISO 8601 seems to be @@ -90,20 +96,5 @@ -- <A HREF="mailto:arthur_david_olson@nih.gov">arthur_david_olson(a)nih.gov</A> (1996-01-04) </P> -<H2>Manavendra Thakur writes:</H2><P> -<A HREF="http://www.dhl.com/dhl/dhlinfo/1bb.html">DHL Information</A> -is run by <A HREF="http://www.dhl.com/">DHL</A> -(the courier company), and it presents a list of the -countries served by that company.... -Here's an example of what you'll see for the -<A HREF="http://www.dhl.com/dhlinfo/country/unitedki.html">United Kingdom</A>. -I find this rather handy, and given that DHL covers 217 countries and -territories, it's pretty comprehensive coverage. -(I have no idea what system DHL is using to calculate the local time, but -it's been accurate so far.) -<P> --- <A HREF="mailto:Manavendra_Thakur@NeXT.COM">Manavendra_Thakur(a)NeXT.COM</A> -(1995-11-06) -</P> </BODY> </HTML> =================================================================== RCS file: RCS/africa,v retrieving revision 1997.10 retrieving revision 1997.10.0.1 diff -u -r1997.10 -r1997.10.0.1 --- africa 1997/12/18 22:47:20 1997.10 +++ africa 1997/12/27 07:53:14 1997.10.0.1 @@ -301,7 +301,7 @@ # Liberia # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): # In 1972 Liberia was the last country to switch -# from a GMT offset that was not a multiple of 15 minutes. +# from a UTC offset that was not a multiple of 15 minutes. # Howse reports that it was in honor of their president's birthday. # Shanks reports the date as May 1, whereas Howse reports Jan; go with Shanks. # For Liberia before 1972, Shanks reports -0:44, whereas Howse and Whitman =================================================================== RCS file: RCS/australasia,v retrieving revision 1997.10 retrieving revision 1997.10.0.1 diff -u -r1997.10 -r1997.10.0.1 --- australasia 1997/12/18 22:47:21 1997.10 +++ australasia 1997/12/27 07:53:14 1997.10.0.1 @@ -303,7 +303,7 @@ Rule NZ 1929 only - Oct 30 2:00 0:30 HD Rule NZ 1930 1933 - Mar Sun>=15 2:00 0 S Rule NZ 1930 1933 - Oct Sun>=8 2:00 0:30 HD -# Whitman says DST went on and off during war years, and the base GMT offset +# Whitman says DST went on and off during war years, and the base UT offset # didn't change until 1945 Apr 30; go with Shanks. Rule NZ 1934 1940 - Apr lastSun 2:00 0 S Rule NZ 1934 1939 - Sep lastSun 2:00 0:30 HD =================================================================== RCS file: RCS/date.1,v retrieving revision 1995.3 retrieving revision 1995.3.0.1 diff -u -r1995.3 -r1995.3.0.1 --- date.1 1995/03/11 17:55:46 1995.3 +++ date.1 1997/12/27 07:53:14 1995.3.0.1 @@ -131,7 +131,7 @@ These options are available: .TP .BR \-u " or " \-c -Use GMT when setting and showing the date and time. +Use UTC when setting and showing the date and time. .TP .B \-n Do not notify other networked systems of the time change. @@ -141,7 +141,7 @@ (The kernel-stored DST type is used mostly by ``old'' binaries.) .TP .BI "\-t " minutes-west -Set the kernel-stored ``minutes west of GMT'' value to the one given on the +Set the kernel-stored ``minutes west of UTC'' value to the one given on the command line. (The kernel-stored DST type is used mostly by ``old'' binaries.) .TP =================================================================== RCS file: RCS/date.c,v retrieving revision 1997.1 retrieving revision 1997.1.0.1 diff -u -r1997.1 -r1997.1.0.1 --- date.c 1997/01/21 00:02:25 1997.1 +++ date.c 1997/12/27 07:53:14 1997.1.0.1 @@ -123,7 +123,7 @@ switch (ch) { default: usage(); - case 'u': /* do it in GMT */ + case 'u': /* do it in UTC */ case 'c': dogmt(); break; @@ -143,7 +143,7 @@ wildinput(_("-t value"), optarg, _("must be a non-negative number")); break; - case 't': /* minutes west of GMT */ + case 't': /* minutes west of UTC */ if (tflag) { (void) fprintf(stderr, _("date: error: multiple -t's used")); @@ -222,7 +222,7 @@ ** TZ=America/New_York date 8712311859.60 ** when the leap second was inserted.) ** The normal check won't work since - ** the given time is valid in GMT. + ** the given time is valid in UTC. */ if (atoi(cp + 1) >= SECSPERMIN) wildinput(_("time"), value, =================================================================== RCS file: RCS/etcetera,v retrieving revision 1997.10 retrieving revision 1997.10.0.1 diff -u -r1997.10 -r1997.10.0.1 --- etcetera 1997/12/18 22:47:21 1997.10 +++ etcetera 1997/12/27 07:53:14 1997.10.0.1 @@ -20,7 +20,7 @@ # We use POSIX-style signedness in the names and output, # internal-style signedness in the specifications. -# For example, TZ=Etc/GMT+4 corresponds to 4 hours _behind_ GMT; +# For example, TZ=Etc/GMT+4 corresponds to 4 hours _behind_ UTC; # it is equivalent to TZ=GMT+4, which is implemented directly as per POSIX. # Earlier incarnations of this package were not POSIX-compliant, =================================================================== RCS file: RCS/europe,v retrieving revision 1997.10 retrieving revision 1997.10.0.1 diff -u -r1997.10 -r1997.10.0.1 --- europe 1997/12/18 22:47:23 1997.10 +++ europe 1997/12/27 07:53:14 1997.10.0.1 @@ -1040,13 +1040,7 @@ 1:00 EU CE%sT # Bosnia and Herzegovina -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Sarajevo 1:13:40 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT +# see Yugoslavia # Bulgaria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -1066,13 +1060,7 @@ 2:00 E-Eur EE%sT # Croatia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Zagreb 1:03:52 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT +# see Yugosloavia # Czech Republic # Gregorian calendar adopted 1584-01-17. @@ -1192,13 +1180,14 @@ # France # Gregorian calendar adopted 1582-12-20. -# French Revolutionary calendar used 1792-09-22 - 1805-12-31. +# French Revolutionary calendar used 1793-11-24 through 1805-12-31, +# and (in Paris only) 1871-05-06 through 1871-05-23. # # Shanks seems to use `24:00' ambiguously; we resolve it with Whitman. # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule France 1916 only - Jun 14 23:00s 1:00 S -Rule France 1916 1919 - Oct Sun>=1 0:00 0 - +Rule France 1916 1919 - Oct Sun>=1 23:00s 0 - Rule France 1917 only - Mar 24 23:00s 1:00 S Rule France 1918 only - Mar 9 23:00s 1:00 S Rule France 1919 only - Mar 1 23:00s 1:00 S @@ -1230,27 +1219,34 @@ # The French rules for 1941-1944 were not used in Paris, # but were used in other places (e.g. Monaco). Rule France 1941 only - May 5 0:00 2:00 DS -Rule France 1941 only - Oct 6 1:00 1:00 S -Rule France 1942 only - Mar 8 0:00 2:00 DS +# Shanks says this transition occurred at Oct 6 1:00, +# but go with Denis.Excoffier(a)ens.fr (1997-12-12), +# who quotes the Ephemerides Astronomiques for 1998 from Bureau des Longitudes +# as saying 5/10/41 22hUT. +Rule France 1941 only - Oct 6 0:00 1:00 S +Rule France 1942 only - Mar 9 0:00 2:00 DS Rule France 1942 only - Nov 2 3:00 1:00 S Rule France 1943 only - Mar 29 2:00 2:00 DS -Rule France 1943 only - Nov 4 3:00 1:00 S +Rule France 1943 only - Oct 4 3:00 1:00 S Rule France 1944 only - Apr 3 2:00 2:00 DS Rule France 1944 only - Oct 8 1:00 1:00 S Rule France 1945 only - Apr 2 2:00 2:00 DS Rule France 1945 only - Sep 16 3:00 0 - -Rule France 1976 only - Mar 28 2:00s 1:00 S -Rule France 1976 only - Sep lastSun 2:00s 0 - +# Shanks gives Mar 28 2:00 and Sep 26 3:00; +# go with Excoffier's 28/3/76 0hUT and 25/9/76 23hUT. +Rule France 1976 only - Mar 28 1:00 1:00 S +Rule France 1976 only - Sep 26 1:00 0 - # Shanks gives 0:09 for Paris Mean Time, and Whitman gives 0:09:05, # but Howse quotes the actual French legislation as saying 0:09:21. # Go with Howse. Howse writes that the time in France was officially based # on PMT-0:09:21 until 1978-08-09, when the time base finally switched to UTC. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 +Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time - 0:00 France WE%sT 1940 Jun 14 +# Shanks gives 1940 Jun 14 0:00; go with Excoffier's 14/6/40 22hUT. + 0:00 France WE%sT 1940 Jun 14 23:00 1:00 C-Eur CE%sT 1944 Aug 25 - 0:00 France WE%sT 1945 Sep 16 3:00 + 0:00 France WE%sT 1945 Sep 16 3:00 1:00 France CE%sT 1977 1:00 EU CE%sT @@ -1565,13 +1561,7 @@ 1:00 EU CE%sT # Macedonia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Skopje 1:25:44 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT +# see Yugoslavia # Malta # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -1961,13 +1951,7 @@ Link Europe/Prague Europe/Bratislava # Slovenia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Ljubljana 0:58:04 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT +# see Yugoslavia # Spain # Gregorian calendar adopted 1582-10-15. @@ -2072,6 +2056,8 @@ 1:00 EU CE%sT # Switzerland +# The Gregorian calendar was introduced gradually in Switzerland, +# by omitting leap years during 1583-1812. # From Howse (1988), p 82: # By the end of the 18th century clocks and watches became commonplace # and their performance improved enormously. Communities began to keep @@ -2211,6 +2197,10 @@ # Shanks doesn't give as much detail, so go with Kozelj. 1:00 - CET 1982 Nov 27 1:00 EU CE%sT +Link Europe/Belgrade Europe/Ljubljana # Slovenia +Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina +Link Europe/Belgrade Europe/Skopje # Macedonia +Link Europe/Belgrade Europe/Zagreb # Croatia ############################################################################### =================================================================== RCS file: RCS/leapseconds,v retrieving revision 1997.2 retrieving revision 1997.2.0.1 diff -u -r1997.2 -r1997.2.0.1 --- leapseconds 1997/02/27 23:03:42 1997.2 +++ leapseconds 1997/12/27 07:53:14 1997.2.0.1 @@ -17,7 +17,7 @@ # Leap YEAR MON DAY 23:59:59 - R/S # If the leapsecond is Rolling (R) the given time is local time -# If the leapsecond is Stationary (S) the given time is GMT +# If the leapsecond is Stationary (S) the given time is UTC # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S =================================================================== RCS file: RCS/localtime.c,v retrieving revision 1997.7 retrieving revision 1997.7.0.1 diff -u -r1997.7 -r1997.7.0.1 --- localtime.c 1997/09/04 20:54:53 1997.7 +++ localtime.c 1997/12/27 07:53:14 1997.7.0.1 @@ -60,11 +60,11 @@ static const char gmt[] = "GMT"; struct ttinfo { /* time type information */ - long tt_gmtoff; /* GMT offset in seconds */ + long tt_gmtoff; /* UTC offset in seconds */ int tt_isdst; /* used to set tm_isdst */ int tt_abbrind; /* abbreviation list index */ int tt_ttisstd; /* TRUE if transition is std time */ - int tt_ttisgmt; /* TRUE if transition is GMT */ + int tt_ttisgmt; /* TRUE if transition is UTC */ }; struct lsinfo { /* leap second information */ @@ -588,8 +588,8 @@ } /* -** Given the Epoch-relative time of January 1, 00:00:00 GMT, in a year, the -** year, a rule, and the offset from GMT at the time that rule takes effect, +** Given the Epoch-relative time of January 1, 00:00:00 UTC, in a year, the +** year, a rule, and the offset from UTC at the time that rule takes effect, ** calculate the Epoch-relative time that rule takes effect. */ @@ -675,10 +675,10 @@ } /* - ** "value" is the Epoch-relative time of 00:00:00 GMT on the day in + ** "value" is the Epoch-relative time of 00:00:00 UTC on the day in ** question. To get the Epoch-relative time of the specified local ** time on that day, add the transition time and the current offset - ** from GMT. + ** from UTC. */ return value + rulep->r_time + offset; } @@ -1065,7 +1065,7 @@ #ifdef TM_ZONE /* ** Could get fancy here and deliver something such as - ** "GMT+xxxx" or "GMT-xxxx" if offset is non-zero, + ** "UTC+xxxx" or "UTC-xxxx" if offset is non-zero, ** but this is no time for a treasure hunt. */ if (offset != 0) @@ -1576,7 +1576,7 @@ /* ** IEEE Std 1003.1-1988 (POSIX) legislates that 536457599 -** shall correspond to "Wed Dec 31 23:59:59 GMT 1986", which +** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which ** is not the case if we are accounting for leap seconds. ** So, we provide the following conversion routines for use ** when exchanging timestamps with POSIX conforming systems. =================================================================== RCS file: RCS/northamerica,v retrieving revision 1997.10 retrieving revision 1997.10.0.1 diff -u -r1997.10 -r1997.10.0.1 --- northamerica 1997/12/18 22:47:24 1997.10 +++ northamerica 1997/12/27 07:53:14 1997.10.0.1 @@ -651,6 +651,18 @@ # Nipigon (EST) and Rainy River (CST) are the largest that we know of. # Far west Ontario is like Winnipeg; far east Quebec is like Halifax. +# From Paul Eggert (1997-10-17): +# msb(a)sq.com writes that an article in the 1997-10-14 Toronto Star +# says that Atikokan, Ontario currently does not observe DST, +# but will vote on 11-10 whether to use EST/EDT. +# He also writes that the Ontario Time Act (1990, Chapter T.9) +# <URL:http://www.gov.on.ca/MBS/english/publications/statregs/conttext.html> +# says that Ontario east of 90W uses EST/EDT, and west of 90W uses CST/CDT. +# Officially Atikokan is therefore on CST/CDT, and most likely this report +# concerns a non-official time observed as a matter of local practice. +# For what it's worth, Shanks (1995) says that Atikokan has agreed with +# Rainy River ever since standard time was introduced. + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mont 1917 only - Mar 25 2:00 1:00 D Rule Mont 1917 only - Apr 24 0:00 0 S =================================================================== RCS file: RCS/time2posix.3,v retrieving revision 1.1 retrieving revision 1.1.0.1 diff -u -r1.1 -r1.1.0.1 --- time2posix.3 1997/05/03 22:52:22 1.1 +++ time2posix.3 1997/12/27 07:53:14 1.1.0.1 @@ -18,7 +18,7 @@ IEEE Standard 1003.1 (POSIX) legislates that a time_t value of -536457599 shall correspond to "Wed Dec 31 23:59:59 GMT 1986." +536457599 shall correspond to "Wed Dec 31 23:59:59 UTC 1986." This effectively implies that POSIX time_t's cannot include leap seconds and, therefore, =================================================================== RCS file: RCS/tzfile.5,v retrieving revision 1997.8 retrieving revision 1997.8.0.1 diff -u -r1997.8 -r1997.8.0.1 --- tzfile.5 1997/12/18 22:45:42 1997.8 +++ tzfile.5 1997/12/27 07:53:14 1997.8.0.1 @@ -18,7 +18,7 @@ in order: .TP .I tzh_ttisgmtcnt -The number of GMT/local indicators stored in the file. +The number of UTC/local indicators stored in the file. .TP .I tzh_ttisstdcnt The number of standard/wall indicators stored in the file. @@ -79,7 +79,7 @@ .IR tt_abbrind . In each structure, .I tt_gmtoff -gives the number of seconds to be added to GMT, +gives the number of seconds to be added to UTC, .I tt_isdst tells whether .I tm_isdst @@ -114,9 +114,9 @@ .PP Finally there are .I tzh_ttisgmtcnt -GMT/local indicators, each stored as a one-byte value; +UTC/local indicators, each stored as a one-byte value; they tell whether the transition times associated with local time types -were specified as GMT or local time, +were specified as UTC or local time, and are used when a time zone file is used in handling POSIX-style time zone environment variables. .PP =================================================================== RCS file: RCS/tzfile.h,v retrieving revision 1997.8 retrieving revision 1997.8.0.1 diff -u -r1997.8 -r1997.8.0.1 --- tzfile.h 1997/12/18 22:42:49 1997.8 +++ tzfile.h 1997/12/27 07:53:14 1997.8.0.1 @@ -64,7 +64,7 @@ ** tzh_timecnt (char [4])s coded transition times a la time(2) ** tzh_timecnt (unsigned char)s types of local time starting at above ** tzh_typecnt repetitions of -** one (char [4]) coded GMT offset in seconds +** one (char [4]) coded UTC offset in seconds ** one (unsigned char) used to set tm_isdst ** one (unsigned char) that's an abbreviation list index ** tzh_charcnt (char)s '\0'-terminated zone abbreviations @@ -77,7 +77,7 @@ ** if absent, transition times are ** assumed to be wall clock time ** tzh_ttisgmtcnt (char)s indexed by type; if TRUE, transition -** time is GMT, if FALSE, +** time is UTC, if FALSE, ** transition time is local time ** if absent, transition times are ** assumed to be local time =================================================================== RCS file: RCS/zdump.c,v retrieving revision 1997.3 retrieving revision 1997.3.0.1 diff -u -r1997.3 -r1997.3.0.1 --- zdump.c 1997/03/07 21:06:32 1997.3 +++ zdump.c 1997/12/27 07:53:14 1997.3.0.1 @@ -344,7 +344,7 @@ (void) printf("%-*s ", (int) longest, zone); if (v) - (void) printf("%.24s GMT = ", asctime(gmtime(&t))); + (void) printf("%.24s UTC = ", asctime(gmtime(&t))); tmp = localtime(&t); (void) printf("%.24s", asctime(tmp)); if (*abbr(tmp) != '\0') =================================================================== RCS file: RCS/zic.8,v retrieving revision 1997.8 retrieving revision 1997.8.0.1 diff -u -r1997.8 -r1997.8.0.1 --- zic.8 1997/12/18 22:43:40 1997.8 +++ zic.8 1997/12/27 07:53:14 1997.8.0.1 @@ -272,13 +272,13 @@ zone. .TP .B GMTOFF -The amount of time to add to GMT to get standard time in this zone. +The amount of time to add to UTC to get standard time in this zone. This field has the same format as the .B AT and .B SAVE fields of rule lines; -begin the field with a minus sign if time must be subtracted from GMT. +begin the field with a minus sign if time must be subtracted from UTC. .TP .B RULES/SAVE The name of the rule(s) that apply in the time zone or, @@ -299,10 +299,10 @@ separates standard and daylight abbreviations. .TP .B UNTIL -The time at which the GMT offset or the rule(s) change for a location. +The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, -the time zone information is generated from the given GMT offset +the time zone information is generated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT columns of a rule; trailing columns can be omitted, and default to the @@ -392,7 +392,7 @@ field should be (an abbreviation of) .q Stationary -if the leap second time given by the other fields should be interpreted as GMT +if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) .q Rolling =================================================================== RCS file: RCS/zic.c,v retrieving revision 1997.8 retrieving revision 1997.8.0.1 diff -u -r1997.8 -r1997.8.0.1 --- zic.c 1997/12/18 22:39:55 1997.8 +++ zic.c 1997/12/27 07:53:14 1997.8.0.1 @@ -1020,7 +1020,7 @@ } z.z_filename = filename; z.z_linenum = linenum; - z.z_gmtoff = gethms(fields[i_gmtoff], _("invalid GMT offset"), TRUE); + z.z_gmtoff = gethms(fields[i_gmtoff], _("invalid UTC offset"), TRUE); if ((cp = strchr(fields[i_format], '%')) != 0) { if (*++cp != 's' || strchr(cp, '%') != 0) { error(_("invalid abbreviation format")); @@ -1630,7 +1630,7 @@ INITIALIZE(ktime); if (useuntil) { /* - ** Turn untiltime into GMT + ** Turn untiltime into UTC ** assuming the current gmtoff and ** stdoff values. */

1 0

tzcode1997h.tar.gz and tzdata1997j.tar.gz
by ado Dec. 18, 1997

Dec. 18, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997h.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997j.tar.gz are now available. These involve the minor changes to put "TZif" at the start of each time zone information file; a rule has also been added to the Makefile so you can make zones to just recompile the zone information files (rather than doing a full "make install" with its other effects). Folks had concerns about the "beta" approach to time stamping of files; I expect to see some proposals for alternate approaches on the mailing list shortly. Note that ASCII stamps of the form yyyy-mm-dd hh:mm:ss or yyyy-mm-dd hh:mm:ss UCT (or whatever variant of "UCT" is standard-compliant these days) will "strcmp" correctly, are human readable, and avoid 2038 problems (though they do, of course, have 9999 problems). --ado

1 0

Review of tzbeta code
by John Cowan Dec. 18, 1997

Dec. 18, 1997

I believe the proposed mechanism for implementing "Updated" timestamps is flawed, and should be modified before leaving beta status. The current design allows either a rule or a zone to be marked as Updated at a certain time, thus. Special comments in the zoneinfo source files of the form #Updated Zone <zonename> <year> [month day hh:mm:ss] or #Updated Rule <rulename> <year> [month day hh:mm:ss] are understood as indicating that the specified Zone or Rule was updated at the specified time. Each binary zoneinfo file is marked to indicate the latest #Updated time associated with it. This is stored in the form "yyyy-mm-dd hh:mm:ss". The beta software currently doesn't actually examine the binary stamp, but the intention is obviously to allow automated supercession of obsolete zoneinfo files. The trouble with this stamp, of course, is that it lacks any indication of time zone! Formally, this does not matter, because the data is read from the source files in ASCII form and written to the binary file in ASCII form. However, comparing two binary files to see which one is more current is an undefined operation, because there is no indication of whether the stamp is UTC, or the zone's own time, or ADO's personal time zone, or what. This will become particularly important if an erroneous source file is issued, because a correction might very well come out quickly, in less than a day. If the correction comes from a different physical location, the #Updated stamp might appear to be earlier in time on the corrected file than on the erroneous one. The results would be most unfortunate. This problem could be resolved by convention, such as always using GMT #Updated values, but this would not be enforced. It would be better, IMHO, to require a <zonename> to be supplied. However, it would probably be a bad idea to make zic runs depend on the pre-existence of a zoneinfo implementation, so the <zonename> could be required to be "GMT" or "UTC". For the same kinds of reasons, the stamp value in the binary zoneinfo files should be stored as a big-endian 32-bit time_t, like other GMT times. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org e'osai ko sarji la lojban

1 0

problem with tz mailling list?
by Paul Eggert Dec. 18, 1997

Dec. 18, 1997

I got the following bounce message from elsie.nci.nih.gov; is there some problem with the tz mailing list? ------- Start of forwarded message ------- Return-Path: <Mailer-Daemon(a)elsie.nci.nih.gov> Received: from red.twinsun.com (red-office.twinsun.com [192.54.239.70]) by tattoo (SMI-8.6/SMI-SVR4) with SMTP id LAA06184 for <eggert@tattoo>; Thu, 18 Dec 1997 11:32:55 -0800 Received: from alcor.twinsun.com (alcor.twinsun.com [198.147.65.9]) by red.twinsun.com (SMI-8.6/SMI-SVR4) with SMTP id LAA14437 for <eggert(a)twinsun.com>; Thu, 18 Dec 1997 11:32:55 -0800 Received: from elsie.nci.nih.gov (elsie.nci.nih.gov [165.112.73.1]) by alcor.twinsun.com (8.8.5/8.7.3) with SMTP id LAA29057 for <eggert(a)twinsun.com>; Thu, 18 Dec 1997 11:28:36 -0800 (PST) Received: by elsie.nci.nih.gov (4.1/SMI-4.1) id AB06282; Thu, 18 Dec 97 14:33:19 EST Date: Thu, 18 Dec 97 14:33:19 EST From: Mailer-Daemon(a)elsie.nci.nih.gov (Mail Delivery Subsystem) Subject: Returned mail: Service unavailable Message-Id: <9712181933.AB06282(a)elsie.nci.nih.gov> To: <eggert(a)twinsun.com> Content-Length: 3491 Status: ----- Transcript of session follows ----- <<< HELO alcor.twinsun.com <<< MAIL From:<eggert(a)twinsun.com> <<< RCPT To:<tz(a)elsie.nci.nih.gov> <<< DATA <<< QUIT Cannot exec '/usr/local/etc/smrsh' errno=2 554 "|exec /mnt/ado/slist/.bin/flist tz"... Service unavailable 554 "|exec /mnt/ado/slist/.bin/flist tz"... Service unavailable ----- Unsent message follows ----- Return-Path: <eggert(a)twinsun.com> Received: from alcor.twinsun.com by elsie.nci.nih.gov (4.1/SMI-4.1) id AA06280; Thu, 18 Dec 97 14:33:19 EST Received: from red.twinsun.com ([192.54.239.70]) by alcor.twinsun.com (8.8.5/8.7.3) with SMTP id LAA29052; Thu, 18 Dec 1997 11:27:54 -0800 (PST) Received: from shade.twinsun.com (shade.twinsun.com [192.54.239.27]) by red.twinsun.com (SMI-8.6/SMI-SVR4) with SMTP id LAA14404; Thu, 18 Dec 1997 11:32:06 -0800 Received: from (eggert@localhost) by shade.twinsun.com (SMI-8.6/SMI-SVR4) id LAA01366; Thu, 18 Dec 1997 11:31:47 -0800 Date: Thu, 18 Dec 1997 11:31:47 -0800 Message-Id: <199712181931.LAA01366(a)shade.twinsun.com> From: Paul Eggert <eggert(a)twinsun.com> To: bsawyer(a)mtnia.com Cc: tz(a)elsie.nci.nih.gov In-Reply-To: <9712181343.AA04768(a)elsie.nci.nih.gov> (OLSONA(a)dc37a.nci.nih.gov) Subject: Re: FW: "info about the world time zones" References: <9712181343.AA04768(a)elsie.nci.nih.gov> From: Brian Sawyer[SMTP:bsawyer@mtnia.com] Sent: Thursday, December 18, 1997 1:42 AM I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. It's not as simple as that, since differences between cities vary with time. For example, during the summer Phoenix is two hours behind Marshalltown, but during the winter, it's only one hour behind. If you just want a simple listing with major cities, you can use the tz database at <ftp://elsie.nci.nih.gov/pub/>, using America/Chicago to represent Marshalltown (this should be valid for dates at least back to 1970). For example, here's a shell transcript to illustrate the current times in Marshalltown and Los Angeles. $ TZ=America/Chicago date # current time in Marshalltown: Thu Dec 18 13:26:06 CST 1997 $ TZ=America/Los_Angeles date # current time in Los Angeles: Thu Dec 18 11:26:06 PST 1997 If you're building a web site, this sort of thing can be easily done in a CGI script; see <http://www.bsdi.com/date> for an example of this. If you want more detailed listings, by far the best tabular source of historical time zone data that I know of are the following books, which contain location names and time zone histories for thousands of locations around the globe. They will tell you more about Marshalltown's time zone history than you probably know yourself. Thomas G. Shanks, The American Atlas (5th edition), San Diego: ACS Publications, Inc. (1991). Thomas G. Shanks, The International Atlas (4th edition), San Diego: ACS Publications, Inc. (1995). [This covers places outside the United States.] A good source for detailed recent time zone data is the International Air Transport Association's Standard Schedules Information Manual (IATA SSIM), published semiannually. However, this is considerably more expensive than Shanks, and it covers only airports, whereas Shanks covers more burgs and hamlets than even my Rand McNally atlas does, and does an excellent job for most places in the US (though even he throws up his hands at the time zone history of Indiana). ------- End of forwarded message -------

1 0

FW: "info about the world time zones"
by Olson, Arthur David Dec. 18, 1997

Dec. 18, 1997

---------- From: Brian Sawyer[SMTP:bsawyer@mtnia.com] Sent: Thursday, December 18, 1997 1:42 AM To: tz(a)elsie.nci.nih.gov Subject: I would like to be on your mailing list. I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. I'm looking for conversions to cities around the world. If you know of a list like this some where, email me back. I can't see the maps very well to see what time it is in another part of the world. I really would like a listing of cities and a + or - hours with them. I hope you can help me out. Thanks for your cooperation and you have a joyous and peaceful holiday season. Sincerely, Brian Sawyer

2 1

I would like to be on your mailing list.
by Brian Sawyer Dec. 18, 1997

Dec. 18, 1997

I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. I'm looking for conversions to cities around the world. If you know of a list like this some where, email me back. I can't see the maps very well to see what time it is in another part of the world. I really would like a listing of cities and a + or - hours with them. I hope you can help me out. Thanks for your cooperation and you have a joyous and peaceful holiday season. Sincerely, Brian Sawyer

1 0

Re: Could you send me a listing of time zones of the world.
by Brian Sawyer Dec. 18, 1997

Dec. 18, 1997

stewart(a)parc.xerox.com wrote: > > In message <34976107.4451(a)mtnia.com> you write: > >Could you email me time zones of the world by plus or minus hours > >converted from the united states times to the other countries, not by > >just a map, but actually listing the city and then if it ahead or behind > >my time. An example would be: > >Marshalltown, Iowa (I'm from here) to Los Angelos -2 hours > > to New York +1 hour > >and so on with conversions from all over the world. > >I have poor eyes and can't see the maps very good. I'm interested in > >time. I thank you for your time and cooperation. You have a Merry > >Christmas and a Happy New Year. > > Merry christmas to you too. Since I don't have a way to do this offhand, > I'll give you a pointer to some information that will allow you to do this. > The folks who maintain the Timezone Database and the various access > routines have a mailing list at tz(a)elsie.nci.nih.gov. Current > versions of their database and access library live at > ftp://elsie.nci.nih.gov/pub. > > -- > Paul I was asked by Paul if I could refer to you on this matter. Can youhelp me out? Can I be on your mailing list. Contact me by email. Thank you for your cooperation and you have a very peaceful and joyous holiday season. Sincerely, Brian Sawyer

1 0

FW: Non Delivery Report
by Olson, Arthur David Dec. 10, 1997

Dec. 10, 1997

Note that Denis is not on the time zone list; you may want to include Denis in any replies. --ado ---------- From: Denis.Excoffier@ens.fr[SMTP:Denis.Excoffier@ens.fr] Sent: Wednesday, December 10, 1997 11:00 AM To: tz(a)elsie.nci.nih.gov Cc: Denis.Excoffier(a)ens.fr Subject: europe France 1891 Extracted from the "europe" file : # Shanks gives 0:09 for Paris Mean Time; go with Whitman's more precise 0:09:05. Should be 0:09:21 instead. By the way, is there somewhere a lastest version of those files ? Another question : my zdump seems to be broken (mentions 1970 too often). Ever heard about this ? (solaris2.5, sparc20) Have a nice day, Scof.

2 1

europe France 1891
by Denis.Excoffier＠ens.fr Dec. 10, 1997

Dec. 10, 1997

Extracted from the "europe" file : # Shanks gives 0:09 for Paris Mean Time; go with Whitman's more precise 0:09:05. Should be 0:09:21 instead. By the way, is there somewhere a lastest version of those files ? Another question : my zdump seems to be broken (mentions 1970 too often). Ever heard about this ? (solaris2.5, sparc20) Have a nice day, Scof.

1 0

Timezone settings for rarotonga wrong.
by Alan Brown Dec. 2, 1997

Dec. 2, 1997

This may have already been corrected. Rarotonga stopped using Daylight Savings Time at least 6 years ago, probably 8 years ago. It's tropical, so there's no sense in them using it. Daylight savngs was used to keep them in sync with New Zealand's daylight savings changes. (Rarotonga is the main island of the Cook Islands - a self-governing state in free association with New Zealand) It's also 10 hours behind GMT/UTC, not ahead of it. Regards Alan Brown.

1 0

FW: Time zone data
by Olson, Arthur David Dec. 1, 1997

Dec. 1, 1997

Charlie Hendricksen is not on the time zone list; please be sure that Charlie is included in any replies. --ado ---------- From: Charlie Hendricksen[SMTP:veritas@u.washington.edu] Sent: Thursday, November 27, 1997 2:58 PM To: ao1d(a)nih.gov Subject: Time zone data Mr. Olson, I found a reference to your timezone work in Bill Thoen's page. I poked around in the ftp server and noticed five files, all nice and big! I experienced difficulty in extracting the tzarchive.gz. so I thought I would contact you before trying any of the other files. I am interested in obtaining a file of the geocoded boundaries of the time zones. I realize that time zones are marvelously complex and frequently changing, so I don't expect perfection. Since I have access to Arc/Info, I prefer the GIS approach to laborious entry of data into a spreadsheet. Can you steer me in the right direction? -- Charlie Hendricksen veritas(a)u.washington.edu

1 0

Happy Leap Second!
by Chris Newman Nov. 24, 1997

Nov. 24, 1997

I hope everyone enjoys their extra second! This also serves as a test to see what really happens if there is a "60" for seconds in the date header. - Chris

3 3

Please help with general info
by Mark Halliday Nov. 22, 1997

Nov. 22, 1997

Hi. I'm working on a project that requires rendering historical data with gmt timestamps in various local timezones. I found this email address in the "europe" file in the glibc-2.0.5\time directory. Can you point me to an overview of the files in this directory, or any other timezone conversion documentation? Who is responsible for maintaining the tables and code is this directory? The Readme file refers to "tzdata1997a package by Arthur David Olsen et.al." I couldn't find any info about this package in the gnu ftp tree. Any help is appreciated. Thanks in advance, Mark # @(#)europe 7.45 # 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 # tz(a)elsie.nci.nih.gov for general use in the future).

1 0

FW: 32-bit 2038 issue
by Olson, Arthur David Nov. 21, 1997

Nov. 21, 1997

> > changing time_t to an unsigned int would give another 68 years > But that would break backward compatibility with many applications. > Few vendors have gone to an unsigned time_t (in fact, I don't know of > any offhand) and there are good reasons for this. A possibility would be to interpret the values in time zone files as unsigned WITHOUT changing the type of time_t. --ado

2 1

beta versions of time zone stuff
by Olson, Arthur David Nov. 20, 1997

Nov. 20, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcodebeta.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdatabeta.tar.gz are now available. 1. zic puts "TZif" at the start of each file it outputs. 2. zic looks for lines of the form #Updated Zone America/New_York 1997 Nov 19 17:58:00 and #Updated Rule NYC 1997 Nov 19 17:58:00 and, when generating output for a zone, stamps the output with the greatest "Updated" time for the zone or any of the rules it uses. Comments heartily solicited! --ado

1 0

Request
by Gatsometer Nov. 17, 1997

Nov. 17, 1997

Hello everyone, I am Peter Smit and working for Gatsometer Holland in R&D. Our equipment for traffic control is exported all over the world. I am looking for some data base or algorithm that produces GMT offset or TZ name if longitude and latitude are input from GPS. Perhaps any of you know someone or an institute that can help. I have taked a look at ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz already and found there the file zone.tab. But maybe someone knows some other stuff. Thanks for your response. Regards, Peter Smit

1 0

`AET' vs `GST' for time in United Arab Emirates
by Paul Eggert Nov. 12, 1997

Nov. 12, 1997

In <news:641quc$182@t1.emirates.net.ae> (1997-11-08), framness(a)EMIRATES.NET.AE (Mark Framness) writes that he uses AET as a string that he made up for ``Arab Emirates Time''. Currently the tz database at ftp://elsie.nci.nih.gov/pub/ uses `GST' for the Persian Gulf states, but that was an abbreviation that I invented from whole cloth, and this news posting suggests that the tz database should use ISO country codes instead for the Persian Gulf area. Similarly for `AST/ADT' for Arabia Standard/Daylight Time. Comments?

1 0

Re: 32-bit 2038 issue
by Joel.Tornatore＠Eng.Sun.COM Nov. 11, 1997

Nov. 11, 1997

changing time_t to an unsigned int would give another 68 years without any of the size/performance problems mentioned in Tom's email. joel ## From tomp(a)zk3.dec.com Tue Nov 11 12:40:27 1997 ## Old-Return-Path: <tomp(a)zk3.dec.com> ## To: tz(a)elsie.nci.nih.gov ## Cc: Tom Peterson <tomp(a)zk3.dec.com>, simons(a)zk3.dec.com, dlong(a)zk3.dec.com ## Subject: 32-bit 2038 issue ## X-Mts: smtp ## ## ## Has anyone considered what to do about time zone files and the 32-bit 2038 ## issue? This comment from zic.c sums up the problem: ## ## > /* ## > ** The tz file format currently allows at most 32-bit quantities. ## > ** This restriction should be removed before signed 32-bit values ## > ** wrap around in 2038, but unfortunately this will require a ## > ** change to the tz file format. ## > */ ## ## With Y2K bringing attention to time-related problems, there's an increasing ## awareness/concern about the 2038 issue as well. People know it's not just a ## system clock setting issue. The limitations affect projected dates used by ## applications as well. Problems are already cropping up where financial ## institutions can't generate amortization data for 40, 50, etc year loans and ## the like. I expect there are other practical examples as well. ## ## As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit ## time_t's. While this certainly eliminates the 2038 limit, it also creates a ## problem for time zone data files. A time zone file filled with data spanning ## 64-bits of seconds-based time would be huge, not to mention the performance ## problems of accessing it. Some ideas for addressing this problem are: ## ## 1) Expand the date/time boundaries for time zone files to a specific range. ## This would have to balance file size vs anticipated application needs. ## Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? ## Regardless of the range set, this approach only delays the problem. ## ## 2) Find some way to mimic what the zic compiler does at run-time. This might ## involve generating some kind of algorithmic data for each time zone which can ## be used to calculate future transition times, etc on-the-fly. I'm not sure ## this is possible or practical given the varied complexity of time zone rules. ## ## 3) Other ideas??? ## ## Also, with 64-bit time_t's, the tm struct becomes the limiting factor. ## Boundary checks now become an issue for localtime()/gmtime() instead of ## mktime(). This is a problem for standards at a mininum. While mktime() has ## the (somewhat ambiguous) -1 return value for non-representable times, no such ## provision is defined for localtime()/gmtime(). ## ## Any ideas or precedent for addressing this issue? ## ## thanks, ## - Tom ## ## ===================================================================== ## Tom Peterson | DIGITAL UNIX Development Environment ## Digital Equipment Corporation | Phone: (603) 884-7550 ## 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 ## Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com ## ## ##

2 1

Re: 32-bit 2038 issue
by Robert Elz Nov. 11, 1997

Nov. 11, 1997

Date: Tue, 11 Nov 1997 13:50:33 -0800 From: Joel.Tornatore(a)Eng.Sun.COM (Joel Tornatore) Message-ID: <199711112150.NAA26831(a)gap.eng.sun.com> | changing time_t to an unsigned int would give another | 68 years without any of the size/performance problems | mentioned in Tom's email. I made that change back in pre 4.2 bsd days. It turned out that it broke too much - most notably, programs that like to print ctime(0) (and there I mean the time_t with a value of 0, I know ctime really takes a pointed to a time_t, and ctime(0) would be a null pointer). The standard behaviour, anywhere west of Greenwich, was to not print Dec 31 1969 in that case, but some time way into the future, which was not at all what anyone expected. So, before 4.2 was actually released, time_t went back signed again. It was all this that caused some of the time functions able to adapt and work whether time_t turns out to be signed or not. kre

1 0

32-bit 2038 issue
by Tom Peterson Nov. 11, 1997

Nov. 11, 1997

Has anyone considered what to do about time zone files and the 32-bit 2038 issue? This comment from zic.c sums up the problem: > /* > ** The tz file format currently allows at most 32-bit quantities. > ** This restriction should be removed before signed 32-bit values > ** wrap around in 2038, but unfortunately this will require a > ** change to the tz file format. > */ With Y2K bringing attention to time-related problems, there's an increasing awareness/concern about the 2038 issue as well. People know it's not just a system clock setting issue. The limitations affect projected dates used by applications as well. Problems are already cropping up where financial institutions can't generate amortization data for 40, 50, etc year loans and the like. I expect there are other practical examples as well. As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit time_t's. While this certainly eliminates the 2038 limit, it also creates a problem for time zone data files. A time zone file filled with data spanning 64-bits of seconds-based time would be huge, not to mention the performance problems of accessing it. Some ideas for addressing this problem are: 1) Expand the date/time boundaries for time zone files to a specific range. This would have to balance file size vs anticipated application needs. Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? Regardless of the range set, this approach only delays the problem. 2) Find some way to mimic what the zic compiler does at run-time. This might involve generating some kind of algorithmic data for each time zone which can be used to calculate future transition times, etc on-the-fly. I'm not sure this is possible or practical given the varied complexity of time zone rules. 3) Other ideas??? Also, with 64-bit time_t's, the tm struct becomes the limiting factor. Boundary checks now become an issue for localtime()/gmtime() instead of mktime(). This is a problem for standards at a mininum. While mktime() has the (somewhat ambiguous) -1 return value for non-representable times, no such provision is defined for localtime()/gmtime(). Any ideas or precedent for addressing this issue? thanks, - Tom ===================================================================== Tom Peterson | DIGITAL UNIX Development Environment Digital Equipment Corporation | Phone: (603) 884-7550 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com

2 1

request!
by Gatsometer Nov. 11, 1997

Nov. 11, 1997

Hello everyone, I am Peter Smit and working for Gatsometer Holland in R&D. Our equipment for traffic control is exported all over the world. I am looking for some data base or algorithm that produces GMT offset or TZ name if longitude and latitude are input from GPS. Perhaps you know someone or an institute that can help. I have already take a look at ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz and found there the file zone.tab. Thanks for your response. Regards, Peter Smit

1 0