December 2003 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

24:00; Canada
by Olson, Arthur David (NIH/NCI) Dec. 26, 2003

Dec. 26, 2003

Regarding use of "24:00" in data files (which pre-1998 versions of zic can't handle), Martin Smoot wrote: > I would think at some point that we would have to give up on maintaining compatibility with these older versions of zic. after all it has been several years. how many people do not have a compiler to rebuild zic? Visiting this whole 24:00 business didn't happen because of Kiefer Sutherland/Jack Bauer; we did get a report of difficulty from a user trying to pump updated data files through a vendor-supplied zic. If use of 24:00 was in support of some active time zone, we'd have no choice but to abandon efforts at compatibility, but when the use of 24:00 is only to support a limited number of historic transitions in a limited number of places, there's more motive to avoid use of 24:00 (and thus to avoid problems for folks trying to use the data with existing compilers). We do, of course, want to keep the code in place so that people for whom it would be useful can benefit from it. We face more latency in our work with the time zone stuff than do vendors such as Sun with other software. Sun has to implement and distribute changes and give customers time to adopt them before abandoning support. We have to implement and distribute changes, wait for vendors to implement and distribute them, and then wait for customers to adopt them. So our "give up on maintaining compatibility" time frame is, of necessity, longer than folks might be accustomed to. A complicating factor is that the time zone data files do now get processed by alternate readers that aren't part of the time zone package. At this point we've got the "this is a simpler way to do it" comments in the relevant place in the data file. The next step will be to uncomment that stuff and comment out the more complicated (but more generally useable) stuff. I don't know what the best time frame is for doing that; I imagine it's best to do it before the retirement of yours truly (now 8-1/2 years off). ---------------------------------------------- Another piece of fallout from the 24:00 work was the discovery that back during the Great Depression Toronto was making switches at 2:00 a.m. on the first Sunday after the last Saturday in April and September--even if this meant that the switch got pushed back to May or October. Now as currently set up, when zic is asked to make a switch on a day of the month such as... Sun>=25 ...it checks to ensure that there is indeed such a Sunday in the month and fails if there isn't one. I believe it's reasonable to lift this restriction; doing so allows simpler expression of rules covering situations such as those in Toronto, as witness the (regression-tested) changes attached below. As always, the point of the exercise is not so much to deal with what happened in Toronto way back when, but to be prepared to deal with the situation if some wild-eyed legislators decide to adopt such a scheme in the future. --ado ------- zic.c ------- *** /tmp/geta11385 Mon Dec 22 12:35:17 2003 --- /tmp/getb11385 Mon Dec 22 12:35:18 2003 *************** *** 2138,2144 **** wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0 || i >= len_months[isleap(y)][m]) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } --- 2138,2144 ---- wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } ------- northamerica ------- *** /tmp/geta11403 Mon Dec 22 12:35:18 2003 --- /tmp/getb11403 Mon Dec 22 12:35:18 2003 *************** *** 989,1000 **** # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D ! Rule Toronto 1927 1932 - Sep lastSun 2:00 0 S ! Rule Toronto 1928 1931 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1932 only - May 1 2:00 1:00 D ! Rule Toronto 1933 1940 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1933 only - Oct 1 2:00 0 S ! Rule Toronto 1934 1939 - Sep lastSun 2:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D --- 989,998 ---- # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D ! Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S ! Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D ! Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S ! Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D

2 1

Use of FILENAME_MAX
by Klaus Klein Dec. 20, 2003

Dec. 20, 2003

While investigating a recent NetBSD bug report (related but turned out to be not an issue), I noticed a use of FILENAME_MAX in tzload() which seems a little wrong. With FILENAME_MAX being sufficient to hold the longest valid pathname, including terminating NUL, it is not necessary to allocate an additional character for the separating slash between `p' and `name'; if that character was consumed by the concatenation, the resulting string would no longer be a valid pathname due to its excessive length. I've also taken the liberty to rearrange the component addition below which seems to have had part in causing our original submitter's misunderstanding, but that's merely cosmetics. Just nitpicking, - Klaus *** localtime.c 15 Dec 2003 15:13:53 -0000 1.1.1.9 --- localtime.c 20 Dec 2003 20:09:07 -0000 *************** *** 284,302 **** ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX + 1]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /* --- 284,302 ---- ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + 1 + strlen(name)) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /*

1 0

www.bsdi.com/date is dead; is there a good replacement?
by Paul Eggert Dec. 15, 2003

Dec. 15, 2003

For many years "Sources for Time Zone and Daylight Saving Time Data" <http://www.twinsun.com/tz/tz-link.htm> has referred to "Date and Time Gateway" <http://www.bsdi.com/date/> as a simple text-based point-and-click web interface based on the tz data. However, www.bsdi.com has been refusing connections recently. Apparently Wind River (which acquired BSDI a couple of years ago) has decided to shut down BSD/OS. Too bad. I have located <http://www.earth.com/date/> as another web site that serves the same data, but if BSD/OS is being discontinued then I worry that this is only a stopgap. Can anyone suggest a replacement URL? We currently refer to the following URLs but I'm looking for something that is less fancy and that is oriented towards the tz data. http://www.hilink.com.au/times/ http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP http://timezoneconverter.com/ http://www.holidayfestival.com/ http://www.timeanddate.com/worldclock/

1 0

Tzcode2003e.tar.gz and tzdata2003e.tar.gz
by Olson, Arthur David (NIH/NCI) Dec. 15, 2003

Dec. 15, 2003

The files... ftp://elsie.nci.nih.gov/pub/tzcode2003e.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2003e.tar.gz ...are now available. These include the changes I recently circulated on the time zone mailing list (primarily code changes) as well as the changes circulated by Paul Eggert (primarily data changes). There are also minor changes to "Makefile" and "northamerica" (in the latter case, Optimization of the "Toronto" rules). More on "24:00" and Toronto to follow. --ado

1 0

light relief from Australia
by Peter Ilieve Dec. 12, 2003

Dec. 12, 2003

The following appears in this week's New Scientist (13 Dec) Feedback and is available on-line at <http://www.newscientist.com/opinion/opfeedback.jsp>: AFTER 30 years of "daylight saving" - moving the clocks forward in the spring and then back again in the autumn - there is still an Abolish Daylight Saving Committee in New South Wales, Australia. Added to the usual claims of such campaigns - for example, that the extra hour of daylight in the evening in summer fades the curtains - is a new one from ADSC spokeswoman Judith Hall, of Gunnedah, who told the Sydney Morning Herald: "No man has the right to choose the time of the rising and setting of the sun, only God." Reader John McCallum, who told us about this, is surprised Hall doesn't explain why God doesn't simply exercise this choice. When people insist on moving their clocks forward, He should just move the sunrise forward and thwart them that way. Never mind 24:00, I wonder how zic would cope with that. :-) This particular ADSC doesn't seem to have a web presence. Searching for `abolish daylight saving' in the archive box at <http://www.smh.com.au> turns up some stuff but they want money for their archive stories. I found one article for free at <http://www.smh.com.au/articles/2003/10/26/1067103271149.html> but I couldn't find the Jeff Corbett column from 29 Oct mentioned in the archive hit summaries. Peter Ilieve peter(a)aldie.co.uk

1 0

Proposed changes to tz package
by Olson, Arthur David (NIH/NCI) Dec. 10, 2003

Dec. 10, 2003

Here are proposed change to the time zone package. Included: * corrections of the spelling of UNIX and of its trademark holder. * correct version number in iso3166.tab * normalize format of comments in localtime.c * change mktime to search temporally backward through used time corrections when making DST adjustments * change Makefile to generate text versions of man pages and to check for uses of 24:00 in input files * change northamerica to avoid use of 24:00 and to normalize a date appearing in a comment * add workman.sh script for generating text versions of man pages * change zic.c to warn about use of 24:00 if the -v option is used * change zic.8 to document warnings about 24:00 --ado ------- europe ------- *** /tmp/geta11168 Thu Dec 4 12:00:25 2003 --- /tmp/getb11168 Thu Dec 4 12:00:25 2003 *************** *** 1,4 **** ! # @(#)europe 7.84 # 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 --- 1,4 ---- ! # @(#)europe 7.85 # 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 *************** *** 1831,1837 **** # # From Andrey A. Chernov <ache(a)nagual.ru> (1996-10-04): # `MSK' and `MSD' were born and used initially on Moscow computers with ! # Unix-like OSes by several developer groups (e.g. Demos group, Kiae group).... # The next step was the UUCP network, the Relcom predecessor # (used mainly for mail), and MSK/MSD was actively used there. # --- 1831,1837 ---- # # From Andrey A. Chernov <ache(a)nagual.ru> (1996-10-04): # `MSK' and `MSD' were born and used initially on Moscow computers with ! # UNIX-like OSes by several developer groups (e.g. Demos group, Kiae group).... # The next step was the UUCP network, the Relcom predecessor # (used mainly for mail), and MSK/MSD was actively used there. # ------- iso3166.tab ------- *** /tmp/geta11187 Thu Dec 4 12:00:25 2003 --- /tmp/getb11187 Thu Dec 4 12:00:25 2003 *************** *** 1,6 **** # ISO 3166 alpha-2 country codes # ! # @(#)iso3166.tab 1.9 # # From Paul Eggert <eggert(a)twinsun.com> (2003-02-04): # --- 1,6 ---- # ISO 3166 alpha-2 country codes # ! # @(#)iso3166.tab 1.14 # # From Paul Eggert <eggert(a)twinsun.com> (2003-02-04): # ------- localtime.c ------- *** /tmp/geta11206 Thu Dec 4 12:00:25 2003 --- /tmp/getb11206 Thu Dec 4 12:00:25 2003 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.76"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.78"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1053,1060 **** } /* ! * Re-entrant version of localtime ! */ struct tm * localtime_r(timep, tm) const time_t * const timep; --- 1053,1061 ---- } /* ! ** Re-entrant version of localtime. ! */ ! struct tm * localtime_r(timep, tm) const time_t * const timep; *************** *** 1113,1120 **** } /* ! * Re-entrant version of gmtime ! */ struct tm * gmtime_r(timep, tm) const time_t * const timep; --- 1114,1122 ---- } /* ! * Re-entrant version of gmtime. ! */ ! struct tm * gmtime_r(timep, tm) const time_t * const timep; *************** *** 1503,1508 **** --- 1505,1515 ---- register time_t t; register const struct state * sp; register int samei, otheri; + register int sameind, otherind; + register int i; + register int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) *************** *** 1536,1545 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1543,1562 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (i = 0; i < sp->typecnt; ++i) ! seen[i] = FALSE; ! nseen = 0; ! for (i = sp->timecnt - 1; i >= 0; --i) ! if (!seen[sp->types[i]]) { ! seen[sp->types[i]] = TRUE; ! types[nseen++] = sp->types[i]; ! } ! for (sameind = 0; sameind < nseen; ++sameind) { ! samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otherind = 0; otherind < nseen; ++otherind) { ! otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - ------- Makefile ------- *** /tmp/geta11225 Thu Dec 4 12:00:26 2003 --- /tmp/getb11225 Thu Dec 4 12:00:26 2003 *************** *** 1,4 **** ! # @(#)Makefile 7.83 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.89 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 268,274 **** WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ $(WEB_PAGES) checktab.awk ! ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $(MISC) # And for the benefit of csh users on systems that assume the user # shell should be used to handle commands in Makefiles. . . --- 268,274 ---- WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ $(WEB_PAGES) checktab.awk ! ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $(MISC) workman.sh # And for the benefit of csh users on systems that assume the user # shell should be used to handle commands in Makefiles. . . *************** *** 383,392 **** public: $(ENCHILADA) zic -mkdir /tmp/,tzpublic ! for i in $(TDATA) ; do zic -d /tmp/,tzpublic $$i ; done rm -f -r /tmp/,tzpublic $(AWK) -f checktab.awk $(PRIMARY_YDATA) ! tar cf - $(DOCS) $(SOURCES) $(MISC) | gzip -9 > tzcode.tar.gz tar cf - $(DATA) | gzip -9 > tzdata.tar.gz zonenames: $(TDATA) --- 383,394 ---- public: $(ENCHILADA) zic -mkdir /tmp/,tzpublic ! -for i in $(TDATA) ; do zic -v -d /tmp/,tzpublic $$i 2>&1 | grep -v "starting year" ; done ! for i in $(TDATA) ; do zic -d /tmp/,tzpublic $$i; done rm -f -r /tmp/,tzpublic + for i in *.[1-8] ; do sh workman.sh $$i > $$i.txt; done $(AWK) -f checktab.awk $(PRIMARY_YDATA) ! tar cf - $(DOCS) $(SOURCES) $(MISC) *.[1-8].txt | gzip -9 > tzcode.tar.gz tar cf - $(DATA) | gzip -9 > tzdata.tar.gz zonenames: $(TDATA) ------- northamerica ------- *** /tmp/geta11244 Thu Dec 4 12:00:26 2003 --- /tmp/getb11244 Thu Dec 4 12:00:26 2003 *************** *** 1,4 **** ! # @(#)northamerica 7.63 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)northamerica 7.65 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, *************** *** 405,411 **** -7:00 - MST # From Arthur David Olson (1988-02-13): # A writer from the Inter Tribal Council of Arizona, Inc., ! # notes in private correspondence dated 12/28/87 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." (The "only" means that other # tribal nations don't use DST.) --- 405,411 ---- -7:00 - MST # From Arthur David Olson (1988-02-13): # A writer from the Inter Tribal Council of Arizona, Inc., ! # notes in private correspondence dated 1987-12-28 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." (The "only" means that other # tribal nations don't use DST.) *************** *** 951,958 **** Rule Mont 1924 only - May 17 2:00 1:00 D Rule Mont 1924 1926 - Sep lastSun 2:30 0 S Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D ! Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D ! Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Mont 1938 1940 - Apr lastSun 0:00 1:00 D Rule Mont 1938 1939 - Sep lastSun 0:00 0 S Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D --- 951,968 ---- Rule Mont 1924 only - May 17 2:00 1:00 D Rule Mont 1924 1926 - Sep lastSun 2:30 0 S Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D ! # The 1927-to-1937 rules can be expressed more simply as ! # Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D ! # Rule Mont 1927 1937 - Sep lastSat 24:00 0 S ! # The rules below avoid use of 24:00 ! # (which pre-1998 versions of zic cannot handle). ! Rule Mont 1927 only - May 1 0:00 1:00 D ! Rule Mont 1928 1931 - Apr lastSun 0:00 1:00 D ! Rule Mont 1932 only - May 1 0:00 1:00 D ! Rule Mont 1933 1937 - Apr lastSun 0:00 1:00 D ! Rule Mont 1927 1932 - Sep lastSun 0:00 0 S ! Rule Mont 1933 only - Oct 1 0:00 0 S ! Rule Mont 1934 1937 - Sep lastSun 0:00 0 S Rule Mont 1938 1940 - Apr lastSun 0:00 1:00 D Rule Mont 1938 1939 - Sep lastSun 0:00 0 S Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D *************** *** 975,982 **** Rule Toronto 1928 only - Apr lastSun 2:00 1:00 D Rule Toronto 1929 only - Apr lastSun 0:00 1:00 D Rule Toronto 1929 only - Sep lastSun 0:00 0 S ! Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D ! Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Rule Toronto 1938 1940 - Apr lastSun 0:00 1:00 D Rule Toronto 1938 1939 - Sep lastSun 0:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S --- 985,1001 ---- Rule Toronto 1928 only - Apr lastSun 2:00 1:00 D Rule Toronto 1929 only - Apr lastSun 0:00 1:00 D Rule Toronto 1929 only - Sep lastSun 0:00 0 S ! # The 1930-to-1937 rules can be expressed more simply as ! # Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D ! # Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S ! # The rules below avoid use of 24:00 ! # (which pre-1998 versions of zic cannot handle). ! Rule Toronto 1930 1931 - Apr lastSun 0:00 1:00 D ! Rule Toronto 1932 only - May 1 0:00 1:00 D ! Rule Toronto 1933 1937 - Apr lastSun 0:00 1:00 D ! Rule Toronto 1930 1932 - Sep lastSun 0:00 0 S ! Rule Toronto 1933 only - Oct 1 0:00 0 S ! Rule Toronto 1934 1937 - Sep lastSun 0:00 0 S Rule Toronto 1938 1940 - Apr lastSun 0:00 1:00 D Rule Toronto 1938 1939 - Sep lastSun 0:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S ------- private.h ------- *** /tmp/geta11263 Thu Dec 4 12:00:26 2003 --- /tmp/getb11263 Thu Dec 4 12:00:26 2003 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.52"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.53"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 288,294 **** #endif /* HAVE_INCOMPATIBLE_CTIME_R */ /* ! ** UNIX was a registered trademark of UNIX System Laboratories in 1993. */ #endif /* !defined PRIVATE_H */ --- 288,294 ---- #endif /* HAVE_INCOMPATIBLE_CTIME_R */ /* ! ** UNIX was a registered trademark of The Open Group in 2003. */ #endif /* !defined PRIVATE_H */ ------- Theory ------- *** /tmp/geta11282 Thu Dec 4 12:00:26 2003 --- /tmp/getb11282 Thu Dec 4 12:00:27 2003 *************** *** 1,4 **** ! @(#)Theory 7.13 ----- Outline ----- --- 1,4 ---- ! @(#)Theory 7.14 ----- Outline ----- *************** *** 12,18 **** ----- Time and date functions ----- These time and date functions are upwards compatible with POSIX.1, ! an international standard for Unix-like systems. As of this writing, the current edition of POSIX.1 is: Information technology --Portable Operating System Interface (POSIX (R)) --- 12,18 ---- ----- Time and date functions ----- These time and date functions are upwards compatible with POSIX.1, ! an international standard for UNIX-like systems. As of this writing, the current edition of POSIX.1 is: Information technology --Portable Operating System Interface (POSIX (R)) *************** *** 144,150 **** since the format of zic's input changed slightly in late 1994, and many vendors still do not support the new input format. ! * The Unix Version 7 "timezone" function is not present in this package; it's impossible to reliably map timezone's arguments (a "minutes west of GMT" value and a "daylight saving time in effect" flag) to a time zone abbreviation, and we refuse to guess. --- 144,150 ---- since the format of zic's input changed slightly in late 1994, and many vendors still do not support the new input format. ! * The UNIX Version 7 "timezone" function is not present in this package; it's impossible to reliably map timezone's arguments (a "minutes west of GMT" value and a "daylight saving time in effect" flag) to a time zone abbreviation, and we refuse to guess. ------- workman.sh ------- *** /tmp/geta11301 Thu Dec 4 12:00:27 2003 --- /tmp/getb11301 Thu Dec 4 12:00:27 2003 *************** *** 0 **** --- 1,29 ---- + #! /bin/sh + + # @(#)workman.sh 1.7 + + # Tell groff not to emit SGR escape sequences (ANSI color escapes). + GROFF_NO_SGR=1 + export GROFF_NO_SGR + + echo ".am TH + .hy 0 + .na + .. + .rm }H + .rm }F" | nroff -man - ${1+"$@"} | perl -ne ' + chomp; + s/.\010//g; + s/\s*$//; + if (/^$/) { + $sawblank = 1; + next; + } else { + if ($sawblank && $didprint) { + print "\n"; + $sawblank = 0; + } + print "$_\n"; + $didprint = 1; + } + ' ------- zic.c ------- *** /tmp/geta11320 Thu Dec 4 12:00:27 2003 --- /tmp/getb11320 Thu Dec 4 12:00:27 2003 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.113"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.115"; #include "private.h" #include "locale.h" *************** *** 931,936 **** --- 931,938 ---- error(errstring); return 0; } + if (noise && hh == HOURSPERDAY) + warning(_("24:00 not handled by pre-1998 versions of zic")); return eitol(sign) * (eitol(hh * MINSPERHOUR + mm) * eitol(SECSPERMIN) + eitol(ss)); *************** *** 2230,2234 **** } /* ! ** UNIX was a registered trademark of UNIX System Laboratories in 1993. */ --- 2232,2236 ---- } /* ! ** UNIX was a registered trademark of The Open Group in 2003. */ ------- zic.8 ------- *** /tmp/geta11429 Thu Dec 4 12:11:14 2003 --- /tmp/getb11429 Thu Dec 4 12:11:14 2003 *************** *** 81,86 **** --- 81,89 ---- of years representable by .IR time (2) values. + Also complain if a time of 24:00 + (which cannot be handled by pre-1998 versions of zic) + appears in the input. .TP .B \-s Limit time values stored in output files to values that are the same *************** *** 417,420 **** /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.20 --- 420,423 ---- /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.21

5 4

RE: compile errors on timezone database
by Olson, Arthur David (NIH/NCI) Dec. 8, 2003

Dec. 8, 2003

Another possibility is to change from... lastSat 24:00 ...to... lastSat 23:59:59 (meaning that changes will be one second premature and that some binary output files will change, but avoiding the dread 60th second.) --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Wednesday, December 03, 2003 12:41 PM To: Olson, Arthur David (NIH/NCI) Cc: 'Diane Kledzik'; Tz (tz(a)elsie.nci.nih.gov) Subject: RE: compile errors on timezone database On Wed, 3 Dec 2003, Olson, Arthur David (NIH/NCI) wrote: > Another possibility is to change the spelling of... > 24:00 > ...to... > 23:59:60 > ...which works with any version of zic issued 1988 or later. Let's > hear it for leap seconds! Please don't do this. This is a bogus time, because there is no leap second at that time. 24:00 makes a lot more sense. Plus my parsing code already handles it and I don't want to have to make more changes ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

3 2

RE: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 5, 2003

Dec. 5, 2003

The strange Chicago behavior occurs because for a few months back in 1936 Chicago switched to using Eastern Standard Time; mktime ended up using this information when trying to do a DST correction. The change below should "fix" things; it convinces mktime to work temporally backward through time adjustments that have been used in an area when trying to do a DST correction. (Of course if you really did start out with a 1936 time this is the wrong thing to do, but that's fairly unlikely.) --ado ------- localtime.c ------- *** /tmp/geta23340 Fri Nov 28 12:10:57 2003 --- /tmp/getb23340 Fri Nov 28 12:10:57 2003 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.76"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.77"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1503,1508 **** --- 1503,1513 ---- register time_t t; register const struct state * sp; register int samei, otheri; + register int sameind, otherind; + register int i; + register int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) *************** *** 1536,1545 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1541,1560 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (i = 0; i < sp->typecnt; ++i) ! seen[i] = FALSE; ! nseen = 0; ! for (i = sp->timecnt - 1; i >= 0; --i) ! if (!seen[sp->types[i]]) { ! seen[sp->types[i]] = TRUE; ! types[nseen++] = sp->types[i]; ! } ! for (sameind = 0; sameind < nseen; ++sameind) { ! samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otherind = 0; otherind < nseen; ++otherind) { ! otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - -----Original Message----- From: tz-request(a)lecserver.nci.nih.gov [mailto:tz-request@lecserver.nci.nih.gov] On Behalf Of Olson, Arthur David (NIH/NCI) Sent: Tuesday, November 25, 2003 7:40 AM To: Tz (tz(a)elsie.nci.nih.gov) Subject: FW: America/Chicago zone vs mktime w/tm_isdst!=-1 Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

3 2

FW: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 5, 2003

Dec. 5, 2003

Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

2 1