- tz - lists.iana.org

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

IERS Message No. 48: Proceedings of IERS Workshop and Documentati on of ITRF2000
by IERS CB Schwegmann, Wolfgang Nov. 17, 2003

Nov. 17, 2003

*************************************************************************** IERS Message No. 48 November 17, 2003 *************************************************************************** Proceedings of IERS Workshop and Documentation of ITRF2000 Online versions of two IERS Technical Notes are now available at http://www.iers.org/iers/publications/tn/ No. 30: Proceedings of the IERS Workshop on Combination Research and Global Geophysical Fluids. Bavarian Academy of Sciences, Munich, Germany, 18 - 21 November 2002. Edited by Bernd Richter, Wolfgang Schwegmann, and Wolfgang R. Dick. 232 pp. No. 31: Claude Boucher, Zuheir Altamimi, Patrick Sillard, and Martine Feissel-Vernier: The ITRF2000. 289 pp. Both Technical Notes are presented as PDF files. To read these, you need Acrobat Reader, which is free and may be downloaded from http://www.adobe.com/support/downloads/main.html . Acrobat Reader comes also with many new browsers as plug-in, so that it may be already installed at your computer. The printed Technical Notes (TN) will be distributed to all subscribers. In case that you are interested in the printed version and do not know whether your address is on our distribution list for IERS TN, please feel free to contact us. Please let us also know about address changes during the last year. Bernd Richter, Wolfgang Dick and Wolfgang Schwegmann IERS Central Bureau <central_bureau(a)iers.org> *************************************************************************** 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

FW: Europe/Paris timezone bug
by Olson, Arthur David (NIH/NCI) Nov. 17, 2003

Nov. 17, 2003

Jason Parks is not on the time zone list; direct replies appropriately. --ado -----Original Message----- From: Jason Parks [mailto:jason.parks@palmsource.com] Sent: Tuesday, October 28, 2003 6:17 PM To: arthur_david_olson(a)nih.gov Cc: Dianne Hackborn Subject: Europe/Paris timezone bug Hi, There appears to be a bug in the timezone libraries(i've tested against localtime.c 7.76) when dealing with Daylight Saving Time and the France timezone. Daylight saving goes into effect at 3:00am instead of 2:00am. Below I have attached simple test case. This is the output of the test I ran on both Mac(10.2.8) and PalmSim bash-2.05a$ TZ="Europe/Paris" ./a.out when = 0x3f9b0e44 is_dst = 1 zone = CEST Sun Oct 26 01:59:00 2003 when = 0x3f9b0e80 is_dst = 1 zone = CEST Sun Oct 26 02:00:00 2003 when = 0x3f9b11c8 is_dst = 1 zone = CEST Sun Oct 26 02:14:00 2003 when = 0x3f9b2014 is_dst = 0 zone = CET Sun Oct 26 02:15:00 2003 You will notice that the difference between 02:14:00 and 02:15:00 is 3660 which is 61 minutes. If you set the device to 2:14 and wait 46 minutes it will change the time back to 02:00. There should be no difference in setting the time to 02:00, 02:14, or 02:15 since anytime after 02:00 should fall outside of Daylight Saving Time on this date. Thanks, --jason

3 3

FW: Brazil zoneinfo corrections.
by Olson, Arthur David (NIH/NCI) Nov. 9, 2003

Nov. 9, 2003

Rodrigo Severo has been added to the time zone mailing list since this message was received. --ado -----Original Message----- From: Rodrigo Severo [mailto:rodrigo.lists@fabricadeideias.com] Sent: Thursday, October 16, 2003 7:31 PM To: tz(a)lecserver.nci.nih.gov Subject: Brazil zoneinfo corrections. Dear list, First of all, I would like to apologize for the confusion I might have caused with my previous emails. The corrections for the brazilian rules and zones I sent where already included in tzdata. I hope this haven't created any problems. Now I send another set of corrections for the brazilian tz data. I have just finished a full review of its rules and zoneinfo from the decrees list at the Brazilian National Observatory (main source of time info in Brazil, the same source already used by previous authors) with the following problems identified and corrected: 1. The effects of decrees 52700 (1963-10-18) and 53071 (1963-12-03) weren't correctly represented by the data as what they really have done was to make a set of states start DST at 1963-10-23 00:00 and the rest of the country to start DST at 1963-12-09 00:00. Fix: change the rule and all affected zones (almost all of them). Also had to create a new Brasilia zone to acomodate the diferences between Sao_Paulo zone and Goias (GO), Distrito Federal (DF), Parana (PR), Santa Catarina (SC), Rio Grande do Sul (RS). 2. The starting time of DST for 1966 was wrong as the 57843 decree stablishes that DST shall begin at 1966-03-01 01:00 and on 1st of March 00:00 from 1967 and on. Fix: new rule for DST start at 1966. 3. Decree 1252 (1994-09-22) defines that the previous states minus AM _AND_ MT states would have DST during 1994/1995 summer. The author of the previous comment probably relied on the Brazilian National Observatory resume of the decree - which is wrong - and not on the actual decree itself (also available at the Brazilian National Observatory site). Fix: America/Cuiaba zone fix. 4. Fernando de Noronha island had wrong timezone info as it should include all DSTs for the Pernambuco state after 1988 as Fernando de Noronha island became part of the Pernambuco state after the brazilian contitution of 1988. If someone has any doubt about it, please check decree 96676 (pre 1988) which clearly includes Pernambuco state, Fernando de Noronha and Atlantic islands. Compare with decree 98077 (pos 1988) which clearly includes Pernambuco state and Atlantic islands (doesn't mention Fernando de Noronha because it already mentioned Pernambuco). Fix: Include all DSTs for Pernambuco after 1988 and create new zone Atol_das_Rocas for the atlantic islands. Maybe this new zone should be called Brazilian_Atlantic_Islands? Too long? 5. America/Sao_Paulo zone had a DST during the whole 1964. I can't see where it came from. There is no decree mentioning it. Fix: Remove it spurious zone info. The patch I am including here is based on the data available at ftp://elsie.nci.nih.gov/pub/ dated 10/06/2003 01:41:00 PM. If someone has any comments on these changes, please send a copy to my personal email as I not sure if I am already subscribed to this list. Thanks in advance for your attention, 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 ----------------------------------------------------

5 8

Proposed changes for text versions of man pages
by Olson, Arthur David (NIH/NCI) Nov. 8, 2003

Nov. 8, 2003

Here are proposed changes for generating text versions of man pages. --ado ------- Makefile ------- *** /tmp/geta17824 Tue Nov 4 09:43:09 2003 --- /tmp/getb17824 Tue Nov 4 09:43:09 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.85 # 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). *************** *** 257,262 **** --- 257,265 ---- MANS= newctime.3 newstrftime.3 newtzset.3 time2posix.3 \ tzfile.5 tzselect.8 zic.8 zdump.8 DOCS= README Theory $(MANS) date.1 Makefile + TXTS= newctime.3.txt newstrftime.3.txt newtzset.3.txt \ + time2posix.3.txt tzfile.5.txt tzselect.8.txt \ + zic.8.txt zdump.8.txt date.1.txt PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward *************** *** 267,273 **** DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) leapseconds yearistype.sh 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 --- 270,276 ---- DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) leapseconds yearistype.sh WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ ! $(WEB_PAGES) checktab.awk workman.sh ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $(MISC) # And for the benefit of csh users on systems that assume the user *************** *** 374,380 **** clean: rm -f core *.o *.out tzselect zdump zic yearistype date \ ! ,* *.tar.gz names: @echo $(ENCHILADA) --- 377,383 ---- clean: rm -f core *.o *.out tzselect zdump zic yearistype date \ ! ,* *.tar.gz $(TXTS) workman names: @echo $(ENCHILADA) *************** *** 381,397 **** # The zics below ensure that each data file can stand on its own. ! 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) @$(AWK) '/^Zone/ { print $$2 } /^Link/ { print $$3 }' $(TDATA) asctime.o: private.h tzfile.h date.o: private.h difftime.o: private.h --- 384,417 ---- # The zics below ensure that each data file can stand on its own. ! public: $(ENCHILADA) zic $(TXTS) -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) $(TXTS) | gzip -9 > tzcode.tar.gz tar cf - $(DATA) | gzip -9 > tzdata.tar.gz zonenames: $(TDATA) @$(AWK) '/^Zone/ { print $$2 } /^Link/ { print $$3 }' $(TDATA) + newctime.3.txt: newctime.3 + newstrftime.3.txt: newstrftime.3 + newtzset.3.txt: newtzset.3 + time2posix.3.txt: time2posix.3 + tzfile.5.txt: tzfile.5 + tzselect.8.txt: tzselect.8 + zic.8.txt: zic.8 + zdump.8.txt: zdump.8 + date.1.txt: date.1 + + $(TXTS): workman + ./workman $(@:.txt=) > $@ + + workman: workman.sh + cp $? $@ + chmod +x $@ + asctime.o: private.h tzfile.h date.o: private.h difftime.o: private.h ------- workman.sh ------- *** /tmp/geta17843 Tue Nov 4 09:43:16 2003 --- /tmp/getb17843 Tue Nov 4 09:43:16 2003 *************** *** 0 **** --- 1,40 ---- + #! /bin/sh + + # @(#)workman.sh 1.3 + + tty -s + ttyval=$? + + case $# in + 0) nroff -man ;; + 1) if [ -f $1 ] + then + ( echo .hy 0; echo .na ) | nroff -man - "$1" + else + man "$1" + fi ;; + *) man ${1+"$@"} ;; + esac | perl -ne ' + if (($. % 66) <= 7) { + next; + } + if (($. % 66) > (66 - 7)) { + next; + } + chomp; + s/.\010//g; + s/[ ]*$//; + if (/^$/) { + $sawblank = 1; + next; + } else { + if ($sawblank) { + print "\n"; + $sawblank = 0; + } + print "$_\n"; + } + ' | case $ttyval in + 0) more ;; + *) cat ;; + esac

2 1

FW: Link suggestion
by Olson, Arthur David (NIH/NCI) Nov. 8, 2003

Nov. 8, 2003

Tjeerd Kramer is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Tjeerd Kramer [mailto:tjeerd@world-airport-codes.com] Sent: Tuesday, November 04, 2003 12:41 PM To: tz(a)lecserver.nci.nih.gov Subject: Link suggestion Hi, I was wondering if you would mind adding a link to the site I created. The name of the site is World Airport Codes. I saw that your site is currently linking to http://www.airportcitycodes.com/aaa/ so I thought you might want to add my site as well (or instead), since we offer more airports, and more info. World Airport Codes lists details for 9000+ airports all over the world. It has the longitude and latitude, the codes, the elevation level, the runway length, and the cities and countries it is in. You can find the site at www.world-airport-codes.com. Hopefully you will like it and add it to your site at http://www.twinsun.com/tz/tz-link.htm Let me know what you think, Tjeerd -- Tjeerd Kramer World Airport Codes W: www.world-airport-codes.com E: tjeerd(a)world-airport-codes.com

2 1

Link suggestion
by Tjeerd Kramer Nov. 4, 2003

Nov. 4, 2003

Hi, I was wondering if you would mind adding a link to the site I created. The name of the site is World Airport Codes. I saw that your site is currently linking to http://www.airportcitycodes.com/aaa/ so I thought you might want to add my site as well (or instead), since we offer more airports, and more info. World Airport Codes lists details for 9000+ airports all over the world. It has the longitude and latitude, the codes, the elevation level, the runway length, and the cities and countries it is in. You can find the site at www.world-airport-codes.com. Hopefully you will like it and add it to your site at http://www.twinsun.com/tz/tz-link.htm Let me know what you think, Tjeerd -- Tjeerd Kramer World Airport Codes W: www.world-airport-codes.com E: tjeerd(a)world-airport-codes.com

1 0