December 1997 - tz - lists.iana.org

Month 53 bug? (fwd)
by Wim Vandeputte Jan. 9, 1998

Jan. 9, 1998

Hi there, I found a little quirck while playing around with the Y2K problem. I got an apetite for overrun problems, and I was looking for some variations. I found out my '93 motherboard switches from 31/12/1997 to 01/01/1997. Great. :-) Then I found this: ---------- Forwarded message ---------- Date: Wed, 31 Dec 1997 00:03:40 +0100 (MET) From: Wim Vandeputte <bunbun(a)reptile.rug.ac.be> To: Theo de Raadt <deraadt(a)cvs.openbsd.org> Subject: Month 53 bug? eh, this is weird. OpenBSD 2.2 GENERIC#81 i386 date +%W gives 52 date +%V gives 53. is *this* 53'th week of the year? On SunOS 5.5 (Generic_103093-08 sun4d sparc SUNW,SPARCserver-1000) both give 52. On SunOS 5.5.1 (sun4u sparc SUNW,Ultra-1) %V gives 53, %W gives 52. On Linux, +%W gives 52, +%V gives 01 The manpage of strftime says that if the week containing Jan 1 has four or more days in the new year, then it is week 1. This week gives: Thursday (1/1), Friday (2/1), Sat (3/1), Sun (4/1) = 4 days in the new year. So date +%V should produce 1 instead of 53, right? This must be some lib thing.... *-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-* Wim Vandeputte --Comfort is Treachery-- --So pound the nails in tight-- His first reply: >From deraadt(a)cvs.openbsd.orgWed Dec 31 00:32:18 1997 Date: Tue, 30 Dec 1997 16:05:14 -0700 From: Theo de Raadt <deraadt(a)cvs.openbsd.org> To: Wim Vandeputte <bunbun(a)reptile.rug.ac.be> Cc: millert(a)cvs.openbsd.org Subject: Re: Month 53 bug? Hmm, interesting problem. It is possible that some of these systems have an old timezone library. And it is possible that our man page is wrong. Or that our code is wrong, since we don't have the very very latest version of the timezone code (we are about a year out of date with respect to the timezone code, but a cursory examination shows that not much has changed, and we've fixed a few bugs ourselves). > nor more days in the new year, then it is week 1. This week gives: > Thursday (1/1), Friday (2/1), Sat (3/1), Sun (4/1) = 4 days in the new year. Wait, isn't Sunday the first day of the next week? Then it's 3 days in the next week. Ie, look at this: October November December Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 1 2 3 4 1 1 2 3 4 5 6 5 6 7 8 9 10 11 2 3 4 5 6 7 8 7 8 9 10 11 12 13 12 13 14 15 16 17 18 9 10 11 12 13 14 15 14 15 16 17 18 19 20 19 20 21 22 23 24 25 16 17 18 19 20 21 22 21 22 23 24 25 26 27 26 27 28 29 30 31 23 24 25 26 27 28 29 28 29 30 31 30 See? So I think we are right: I think SunOS 5.5 had it wrong, Linux has it wrong, and both SunOS 5.5.1 and OpenBSD 2.2 get it right. Do you now concur? ------------------------------------------------------------------------ I wrote back: >From bunbun(a)reptile.rug.ac.beWed Dec 31 00:34:13 1997 Date: Wed, 31 Dec 1997 00:20:20 +0100 (MET) From: Wim Vandeputte <bunbun(a)reptile.rug.ac.be> To: Theo de Raadt <deraadt(a)cvs.openbsd.org> Subject: Re: Month 53 bug? On Tue, 30 Dec 1997, Theo de Raadt wrote: > Wait, isn't Sunday the first day of the next week? Then it's 3 days > in the next week. Ie, look at this: the man page (old or faulty?) says that "(Monday as the first day of the week)". ^^^^^^^^^^^^^-> the SunOS page says the same. That makes the week go from Mon -> Sun, thus still four days in this week in the next year. Confuse me :-) please (it's running late here :-) *-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-* Wim Vandeputte --Comfort is Treachery-- --So pound the nails in tight-- His reply to this: >From deraadt(a)cvs.openbsd.orgWed Dec 31 00:32:24 1997 Date: Tue, 30 Dec 1997 16:17:40 -0700 From: Theo de Raadt <deraadt(a)cvs.openbsd.org> To: Wim Vandeputte <bunbun(a)reptile.rug.ac.be> Cc: millert(a)cvs.openbsd.org Subject: Re: Month 53 bug? Please never remove cc:'s > > Wait, isn't Sunday the first day of the next week? Then it's 3 days > > in the next week. Ie, look at this: > > the man page (old or faulty?) says that "(Monday as the first day of the > week)". ^^^^^^^^^^^^^-> the SunOS page says the same. > > That makes the week go from Mon -> Sun, thus still four days in this week > in the next year. Ok. Perhaps this is a flaw then. We need to find out which way that needs to work, then. Do you want to do some more research by contacting the people who wrote the library in question? Yeah you do! Go for it: contact tz(a)elsie.nci.nih.gov and keep us informed OK? -------------------------------------------------- So, this brings me to you... what's the next step?

1 1

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