- tz - lists.iana.org

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

Re: Time stamp(s)
by ncm＠cantrip.org Nov. 3, 1997

Nov. 3, 1997

Paul Eggert <eggert(a)twinsun.com> wrote: > From: "Olson, Arthur David" <OLSONA(a)dc37a.nci.nih.gov> > > my guess is that the thing to do is put at the start of the file a > count of the number of bytes worth of stamp that appear, then put > the stamp information itself at the end of the file. > > How would this work with the Unix `file' command? Mr. Eggert's posting seems to confuse two independent improvements: a file magic number and a set of validity timestamps. Of course any "record offset" for the timestamps would come after the magic number. I agree with Mr. Olson that it would be better not to use up all the remaining uncommitted bytes in the record for timestamps, and that placing the offset to such a record elsewhere in the file would be better. Nathan

1 0

Time stamp(s)
by Olson, Arthur David Nov. 1, 1997

Nov. 1, 1997

Whatever number of stamps end up in the file, my guess is that the thing to do is put at the start of the file a count of the number of bytes worth of stamp that appear, then put the stamp information itself at the end of the file. This minimizes the encroachment on the twenty remaining bytes of "reserved for future use" space; it also would allow us to have longish, easy-for-humans-to-read stamp information (either in addition to or instead of shorter, easy-for-computers-to-process information). My sense is that one stamp might be sufficient. A client picking up time zone information from multiple sources would use the one with the largest stamp. The stamp might be automatically generated as a function of the maximum "until" time appearing on a "Zone" line for the zone in question and the maximum "from" and "to" years appearing on a "Rule" line for the zone in question. Doing this would eliminate the need for separate maintenance of information from which to generate stamps; it would also avoid adding information to the zic input files that old versions of zic would not be able to handle. The down side would be that if we learned of a correction to zone information that only affected past times, we wouldn't get an *automatic* update of the stamp for the zone. Comments? --ado

2 1

Proposed DST change for Sydney Olympics
by Eric Ulevik Oct. 26, 1997

Oct. 26, 1997

SOCOG (the Sydney Organizing Commitee for the Olympic Games) have requested that daylight savings time start early in 2000, to make things easier when running the games. The proposed start date is 27 August 2000. This would mean Sydney having eight months of daylight savings time. Apparently the NSW Government is looking favourably on this proposal. Regards, Eric Ulevik Reference: Sunday Telegraph, 26 October 1997, page 26

1 0