- tz - lists.iana.org

FW: NebulaSearch.com Encyclopedia article about "Time zone"
by Olson, Arthur David (NIH/NCI) Jan. 12, 2004

Jan. 12, 2004

Bryan Johnston is not on the time zone mailing list; direct replies appropriately. -ado -----Original Message----- From: Bryan Johnston [mailto:nebulasearch@yahoo.com] Sent: Sunday, January 11, 2004 3:57 AM To: tz(a)lecserver.nci.nih.gov Subject: NebulaSearch.com Encyclopedia article about "Time zone" The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

NebulaSearch.com Encyclopedia article about "Time zone"
by Bryan Johnston Jan. 11, 2004

Jan. 11, 2004

The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

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. 16, 2003

Dec. 16, 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. 9, 2003

Dec. 9, 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. 6, 2003

Dec. 6, 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. 6, 2003

Dec. 6, 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

tzcode port to delphi
by Wayne Stanton Dec. 4, 2003

Dec. 4, 2003

Hi there, Does any know of a port of the tzcode to delphi or another windows specific compiler? thanks Wayne Stanton

1 0

FW: tzcode port to delphi
by Olson, Arthur David (NIH/NCI) Dec. 4, 2003

Dec. 4, 2003

Wayne Stanton is on the time zone mailing list, but at a different address than the one from which the message below originated. --ado -----Original Message----- From: Wayne Stanton [mailto:stantonw@optusnet.com.au] Sent: Wednesday, December 03, 2003 3:11 PM To: 'Tz (tz(a)elsie.nci.nih.gov)' Subject: tzcode port to delphi Hi there, Does any know of a port of the tzcode to delphi or another windows specific compiler? thanks Wayne Stanton

1 0

FW: Addition to http://www.twinsun.com/tz/tz-link.htm
by Olson, Arthur David (NIH/NCI) Dec. 4, 2003

Dec. 4, 2003

Steven R. Loomis has been added to the time zone mailing list after this message was received. --ado -----Original Message----- From: Steven R. Loomis [mailto:srl@jtcsv.com] Sent: Wednesday, December 03, 2003 8:32 PM To: tz(a)lecserver.nci.nih.gov Subject: Addition to http://www.twinsun.com/tz/tz-link.htm The International Components for Unicode library for C/C++ (ICU) uses tzdata in its historic time zone calculations. Our URL is http://oss.software.ibm.com/icu/ Would you consider adding a link to the page http://www.twinsun.com/tz/tz-link.htm ? Thank you and regards, Steven R. Loomis

1 0

Addition to http://www.twinsun.com/tz/tz-link.htm
by Steven R. Loomis Dec. 4, 2003

Dec. 4, 2003

The International Components for Unicode library for C/C++ (ICU) uses tzdata in its historic time zone calculations. Our URL is http://oss.software.ibm.com/icu/ Would you consider adding a link to the page http://www.twinsun.com/tz/tz-link.htm ? Thank you and regards, Steven R. Loomis

1 0

tzcode port to delphi
by Wayne Stanton Dec. 3, 2003

Dec. 3, 2003

Hi there, Does any know of a port of the tzcode to delphi or another windows specific compiler? thanks Wayne Stanton

1 0

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

Dec. 3, 2003

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! --ado -----Original Message----- From: tz-request(a)lecserver.nci.nih.gov [mailto:tz-request@lecserver.nci.nih.gov] On Behalf Of Rodrigo Severo Sent: Wednesday, December 03, 2003 5:58 AM To: 'diane_kledzik(a)notes.ntrs.com' Cc: Tz (tz(a)elsie.nci.nih.gov) Subject: Re: compile errors on timezone database Olson, Arthur David (NIH/NCI) wrote: >Back in 1998 zic was tweaked to accept 24:00 in "AT" fields; my guess >is that the version of zic being used predates that change. (If the >vendor hasn't stripped things and you're on a POSIX system, you can do >a... > what /path/to/the/executable/zic >...to get a version number; anything under 7.94 lacks the tweak; >anything beyond 7.95 has the tweak.) > >Mindful of folks with old compilers, it may be best to change the >northamerica file to avoid use of 24:00, changing the "lastSat 24:00" >references to "lastSun 0:00". (And perhaps using zic should generate >warning messages if a 24:00 shows up and zic's -v option has been >used.) > > Because of the lastSat-might-be-the-last-day-of-the-month issue the Right Thing to be done is to update zic and use the correct zoneinfo definition. Rodrigo Severo -- ---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ----------------------------------------------------

4 3

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

Dec. 3, 2003

Back in 1998 zic was tweaked to accept 24:00 in "AT" fields; my guess is that the version of zic being used predates that change. (If the vendor hasn't stripped things and you're on a POSIX system, you can do a... what /path/to/the/executable/zic ...to get a version number; anything under 7.94 lacks the tweak; anything beyond 7.95 has the tweak.) Mindful of folks with old compilers, it may be best to change the northamerica file to avoid use of 24:00, changing the "lastSat 24:00" references to "lastSun 0:00". (And perhaps using zic should generate warning messages if a 24:00 shows up and zic's -v option has been used.) --ado -----Original Message----- From: Diane Kledzik [mailto:Diane_Kledzik@notes.ntrs.com] Sent: Tuesday, December 02, 2003 12:52 PM To: tz(a)lecserver.nci.nih.gov Cc: eggert(a)twinsun.com Subject: compile errors on timezone database As an fyi, I receive compile errors when I compile (using "zic") the time zone database downloaded in the tzdata2003d.tar file from your ftp://elsie.nci.nih.gov/pub/ site. The error messages read: "northamerica", line 954: invalid time of day "northamerica", line 955: invalid time of day "northamerica", line 978: invalid time of day "northamerica", line 979: invalid time of day Those lines in the northamerica file are below. Is it safe to assume I need to change the 24:00 references to 0:00 instead? Has anyone else run into this problem? Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Thanks for your help, Diane Kledzik

4 3

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

Dec. 2, 2003

Diane Kledzik is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Diane Kledzik [mailto:Diane_Kledzik@notes.ntrs.com] Sent: Tuesday, December 02, 2003 12:52 PM To: tz(a)lecserver.nci.nih.gov Cc: eggert(a)twinsun.com Subject: compile errors on timezone database As an fyi, I receive compile errors when I compile (using "zic") the time zone database downloaded in the tzdata2003d.tar file from your ftp://elsie.nci.nih.gov/pub/ site. The error messages read: "northamerica", line 954: invalid time of day "northamerica", line 955: invalid time of day "northamerica", line 978: invalid time of day "northamerica", line 979: invalid time of day Those lines in the northamerica file are below. Is it safe to assume I need to change the 24:00 references to 0:00 instead? Has anyone else run into this problem? Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Thanks for your help, Diane Kledzik

2 1

compile errors on timezone database
by Diane Kledzik Dec. 2, 2003

Dec. 2, 2003

As an fyi, I receive compile errors when I compile (using "zic") the time zone database downloaded in the tzdata2003d.tar file from your ftp://elsie.nci.nih.gov/pub/ site. The error messages read: "northamerica", line 954: invalid time of day "northamerica", line 955: invalid time of day "northamerica", line 978: invalid time of day "northamerica", line 979: invalid time of day Those lines in the northamerica file are below. Is it safe to assume I need to change the 24:00 references to 0:00 instead? Has anyone else run into this problem? Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Thanks for your help, Diane Kledzik

1 0

FW: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt
by Olson, Arthur David (NIH/NCI) Nov. 26, 2003

Nov. 26, 2003

>From tony.milton(a)bnpparibas.com Wed Nov 26 05:31:29 2003 Return-Path: <tony.milton(a)bnpparibas.com> Received: from lonn000636.uk.net.intra (lonmail3.bnpparibas.com [155.140.121.249]) by lecserver.nci.nih.gov (8.12.10/8.12.10) with ESMTP id hAQAVSpT009346 for <tz-request(a)lecserver.nci.nih.gov>; Wed, 26 Nov 2003 05:31:28 -0500 (EST) Received: from lonn000941.bnpparibas.com (unverified) by lonn000636.uk.net.intra (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6624019c6a0a0747f911d(a)lonn000636.uk.net.intra> for <tz-request(a)lecserver.nci.nih.gov>; Wed, 26 Nov 2003 10:32:29 +0000 Sensitivity: Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt To: tz-request(a)lecserver.nci.nih.gov From: tony.milton(a)bnpparibas.com Date: Wed, 26 Nov 2003 10:31:18 +0000 Message-ID: <OFA28C075F.5DFAFFAA-ON80256DEA.0039CC66(a)bnpparibas.com> X-MIMETrack: Serialize by Router on LONSMTP003/SERVERS/SMTP(Release 5.0.12 |February 13, 2003) at 26/11/2003 10:30:47 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79" Content-Disposition: inline Status: RO --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79 Content-type: text/plain; charset="us-ascii" May be of interest. ---------------------- Forwarded by Tony Milton/UK/EUROPE/GROUP on 26/11/2003 10:30 --------------------------- Internet Internet-Drafts@ietf.org@ietf.org - 25/11/2003 20:25 Please respond to Internet-Drafts(a)ietf.org Sent by: dhcwg-admin(a)ietf.org To: IETF-Announce: ; cc: dhcwg Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Timezone Specifier Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-tz-00.txt Pages : 6 Date : 2003-11-25 This document describes a new DHCPv6 option for passing the client's timezone information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-tz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. mailto:mailserv@ietf.org This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79 Content-type: application/octet-stream; name="draft-ietf-dhc-dhcpv6-opt-tz-00.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-tz-00.txt" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwMy0xMS0yNTE1MTcxNi5J LURAaWV0Zi5vcmc+DQo= --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79--

1 0

[dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt
by tony.milton＠bnpparibas.com Nov. 26, 2003

Nov. 26, 2003

May be of interest. ---------------------- Forwarded by Tony Milton/UK/EUROPE/GROUP on 26/11/2003 10:30 --------------------------- Internet Internet-Drafts@ietf.org@ietf.org - 25/11/2003 20:25 Please respond to Internet-Drafts(a)ietf.org Sent by: dhcwg-admin(a)ietf.org To: IETF-Announce: ; cc: dhcwg Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Timezone Specifier Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-tz-00.txt Pages : 6 Date : 2003-11-25 This document describes a new DHCPv6 option for passing the client's timezone information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-tz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. mailto:mailserv@ietf.org This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.

1 0

America/Chicago zone vs mktime w/tm_isdst!=-1
by Dan Nelson Nov. 24, 2003

Nov. 24, 2003

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

1 0

IERS Message No. 50: WG on Nomenclature for Fundamental Astronomy
by IERS Central Bureau Nov. 21, 2003

Nov. 21, 2003

*************************************************************************** IERS Message No. 50 November 21, 2003 *************************************************************************** IAU Working Group on Nomenclature for Fundamental Astronomy At the IAU XXV General Assembly that met in Sydney in 2003, it was decided that IAU Division 1 would form a new working group to be called Nomenclature for Fundamental Astronomy. The purpose of the working group is to provide proposals for new nomenclature associated with the implementation of the IAU 2000 Resolutions and to make educational efforts to the scientific community regarding the resolutions. The Working Group webpage is now available at http://syrte.obspm.fr/iauWGnfa/. It currently contains the newsletters of the working group and other documents related to its work. Dennis D. McCarthy U. S. Naval Observatory *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0

IERS Message No. 49: IERS Conventions (2003)
by IERS Central Bureau Nov. 19, 2003

Nov. 19, 2003

*************************************************************************** IERS Message No. 49 November 19, 2003 *************************************************************************** IERS Conventions (2003) The IERS Conventions (2003) have been finalized in October 2003. The document can be accessed electronically at http://maia.usno.navy.mil/conv2003.html and the printed version will be available soon as IERS Technical Note 32. Note that when referenced in recommendations and articles published in past years, this document may have been referred to as the IERS Conventions (2000). The content of the web page above is now frozen to the present version of the IERS Conventions. Comments and proposals for their future evolution are invited through the Questionnaire below. Comments may also be sent directly to the principal scientists of the IERS Conventions center Dennis McCarthy (dmc(a)maia.usno.navy.mil) and Gerard Petit (gpetit(a)bipm.org) Questionnaire from the IERS Conventions Center The IERS Conventions (2003) are available at http://maia.usno.navy.mil/conv2000.html or in printed form as IERS Technical Note 32. The IERS Conventions Center invites questions, comments, remarks or suggestions of any type concerning this document specifically in the following areas. The bulleted items are meant to guide but not limit responses. 1. IERS Conventions (2003) 1.1 Content * Value as a general reference document * Value of changes in 2003 vs. Conventions (1996) * Structure of the document * Problems or errors discovered * Models that should be replaced or added * Implementation of associated software 1.2 Availability * Paper edition (forthcoming) * Web site and electronic formats 2. Future IERS Conventions Plans are to continue to have "paper editions," i.e. a reference edition with a label, published at intervals of several years or whenever a major change is needed, especially one that affects the definition of the reference systems or the principal characteristics of the realized frames. Upgrades containing corrections, introduction of explanatory parts, new software implementations, addition of models that do not affect "the principal characteristics" etc., would be provided more frequently by electronic revisions with well-documented revision dates. The IERS Conventions Center invites suggestions of any type concerning these plans specifically in the following areas: 2.1 Preparation * Suggestions for procedures to gather new and updated information, to evaluate proposals for changes and to validate accuracy and consistency of models * Frequency of updates 2.2 Content * Items missing or incorrectly described in Conventions (2003) * Software routines * Technique specific constants and models 2.3 Availability * Value of paper edition in the future * Web site changes * Methods of updating web version (continuous or discrete, e.g. once a year) * Methods to record changes and past versions of text and software * New means of disseminating information such as FAQs, newsgroup, LISTSERV. 3. Interactions between Conventions Center & other IERS components / Technique services To provide further improvements in the operational procedures the Center also invites your comments and suggestions on the following: 3.1 Special Advisory Board The Conventions Center has envisioned that an Advisory Board could be set up to provide overview and guidance. * Would such a board be useful? * Suggestions for how to form such a board * Should it be permanent or temporary? 3.2 Formal acceptance * Should the Conventions be submitted to a formal acceptance process? * Who should be the approving authority and under what conditions? 3.3 Routine interactions * How best to enhance routine interactions with other IERS components and the Technique Centers? * What about other groups outside IERS? Please return replies to G. Petit (gpetit(a)bipm.org) and D.D. McCarthy (dmc(a)maia.usno.navy.mil) before 15 January 2004. *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0