- tz - lists.iana.org

Pulaski County rebels against the Department of Transportation
by Paul Eggert Feb. 8, 2006

Feb. 8, 2006

According to an AP article <http://www.indystar.com/apps/pbcs.dll/article?AID=/20060207/NEWS01/60207040…>, officials in Pulaski County, Indiana, have changed their minds, and want to undo the time-zone change that they asked the feds to grant a few months ago. "While it's official, it's unofficial: We will not set our clocks with Chicago; we'll set our clocks with Indianapolis," said Pulaski County Council President Sam Frain. Even if they follow through with this threat, we won't have to create a new zone; Pulaski County residents can continue to use the America/Indiana/Indianapolis zone. However, we should adjust zone.tab and the comments to make it clear that Pulaski County is still using Indianapolis time.

1 0

FW: America/Edmonton 2007
by Chris Walton-TM Feb. 8, 2006

Feb. 8, 2006

-----Original Message----- From: Chris Walton-TM Sent: February 7, 2006 1:42 AM To: tz(a)lecserver.nci.nih.gov Subject: America/Edmonton 2007 The Alberta government announced on Feb 2 that it will extend daylight savings by four weeks starting in 2007. This will match the changes that have been made in the United States. I am hoping that "America/Edmonton" can be updated in the next tzdata release. Here is a link from the CBC website. http://www.cbc.ca/calgary/story/ca_daylight20060202.html Thanks. -chris

2 1

Re: FW: tzcode2006a.tar.gz on Irix 6.5.18m
by Paul Eggert Feb. 8, 2006

Feb. 8, 2006

Andrew Donaldson <A.Donaldson(a)bom.gov.au> writes: > Yep, that fixes it. Thanks for checking it. > Do you plan to include this in the next version? Yes, I'll submit it as part of my next proposed patch; Arthur David Olson has the final say.

1 0

Re: FW: tzcode2006a.tar.gz on Irix 6.5.18m
by Paul Eggert Feb. 8, 2006

Feb. 8, 2006

Thanks for looking into the problem. zdump.c relies on undefined behavior on overflow, which is the problem here, but if we can assume C99+LIA-1 semantics (the common case) we can get a reliable result. Also, I think it's safer to avoid 'register'. Does the following patch to zdump.c fix things for you? --- zdump.c 2006/02/02 20:42:22 2005.18.0.1 +++ zdump.c 2006/02/08 00:33:28 @@ -418,14 +418,21 @@ _("%s: use of -v on system with floating } } else if (0 > (time_t) -1) { /* - ** time_t is signed. + ** time_t is signed. Assume overflow wraps around. */ - register time_t hibit; + time_t t = 0; + time_t t1 = 1; - for (hibit = 1; (hibit * 2) != 0; hibit *= 2) - continue; - absolute_min_time = hibit; - absolute_max_time = -(hibit + 1); + while (t < t1) { + t = t1; + t1 = 2 * t1 + 1; + } + + absolute_max_time = t; + t = -t; + absolute_min_time = t - 1; + if (t < absolute_min_time) + absolute_min_time = t; } else { /* ** time_t is unsigned.

1 0

RE: OT- trouble connecting to elsie-
by Olson, Arthur David (NIH/NCI) [E] Feb. 7, 2006

Feb. 7, 2006

I've just update the TCP wrapper in user here at elsie; give ftp a try and let me know one way or the other. Thanks! --ado -----Original Message----- From: Dave Cantor [mailto:Dave@Cantor.mv.com] Sent: Monday, February 06, 2006 8:26 AM To: Paul Eggert Cc: tz(a)lecserver.nci.nih.gov Subject: Re: OT- trouble connecting to elsie- On 5 Feb 2006 at 22:59, Paul Eggert wrote: > > Date: Fri, 03 Feb 2006 09:51:19 -0500 > > From: "Dave Cantor" <Dave(a)Cantor.mv.com> > > Message-ID: <43E32797.7719.2F8A382(a)Dave.Cantor.mv.com> > > | I have not been able to connect to elsie.nci.nih.gov via ftp, or, > > | rather, whenever I connect, the remote host disconnects. Is > > | anyone else having this trouble? > In the past this has happened when people attempt to connect to elsie > from blacklisted IP addresses. I don't know who's in charge of the > blacklist, unfortunately. It could be something as simple as the > reverse-DNS entry for your IP address; is it set up properly? As far as I can tell, the reverse-DNS entry is correct: host174-106.defiant.tvcconnect.net, IP address 216.255.174.106, Maybe it's blacklisted for some reason. Thanks, Dave C.

2 1

FW: Bug#351049: libc6: America/Havana DST info wrong for 2005/2006
by Olson, Arthur David (NIH/NCI) [E] Feb. 6, 2006

Feb. 6, 2006

Lionel Elie Mamane is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Lionel Elie Mamane [mailto:lionel@mamane.lu] Sent: Thursday, February 02, 2006 9:18 AM To: Debian Bug Tracking System Subject: Bug#351049: libc6: America/Havana DST info wrong for 2005/2006 Package: libc6 Version: 2.3.5-12.1 Severity: normal Cuba did not switch back to non-DST time on October 2005, but the timezone info in libc thinks it did: Rule Cuba 2005 max - Oct lastSun 0:00s 0 S That line should probably be changed to Rule Cuba 2006 max - Oct lastSun 0:00s 0 S Source: http://www.timeanddate.com/worldclock/timezone.html?n=99 (and a friend that spent vacation in Cuba) Note that the timezone/northamerica says: # From Evert van der Veer via Steffen Thorsen (2004-10-28): # Cuba is not going back to standard time this year. # From Paul Eggert (2004-10-28): # http://www.granma.cu/ingles/2004/septiembre/juev30/41medid-i.html # says that it's due to a problem at the Antonio Guiteras # thermoelectric plant, and says "This October there will be no return # to normal hours (after daylight saving time)". # For now, let's assume that it's a one-year temporary measure. ^^^^^^^^^^^^^^^^^^^^^^^^^ So it became a two-year temporary measure? We are not sure if it won't become a 3+ year temporary measure. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-deb1-64bit Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) -- no debconf information

5 11

RE: Misspelling With the Australia/Lord_Howe Time Zone
by Olson, Arthur David (NIH/NCI) [E] Feb. 6, 2006

Feb. 6, 2006

I failed to find a "load" problem here at elsie (see below). (I also tried looking in the SCCS record to no avail.) --ado Script started on Mon 06 Feb 2006 10:17:36 AM EST lecserver$ ls -l total 0 -rw-r--r-- 1 olsona root 0 Feb 6 10:17 typescript lecserver$ ftp elsie.nci.nih.gov Connected to lecserver. 220 lecserver FTP server (Version wu-2.6.2(4)+connect-dos.patch+realpath.patch Tue Apr 13 15:43:02 EDT 2004) ready. Name (elsie.nci.nih.gov:olsona): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. ftp> binary 200 Type set to I. ftp> prompt Interactive mode off. ftp> cd pub 250 CWD command successful. ftp> get tzcode2006a.tar.gz 200 PORT command successful. 150 Opening BINARY mode data connection for tzcode2006a.tar.gz (180636 bytes). 226 Transfer complete. local: tzcode2006a.tar.gz remote: tzcode2006a.tar.gz 180636 bytes received in 0.031 seconds (5761.77 Kbytes/s) ftp> get tzdata2006a.tar.gz 200 PORT command successful. 150 Opening BINARY mode data connection for tzdata2006a.tar.gz (149612 bytes). 226 Transfer complete. local: tzdata2006a.tar.gz remote: tzdata2006a.tar.gz 149612 bytes received in 0.058 seconds (2507.86 Kbytes/s) ftp> quit 221-You have transferred 330248 bytes in 2 files. 221-Total traffic for this session was 331005 bytes in 2 transfers. 221-Thank you for using the FTP service on lecserver. 221 Goodbye. lecserver$ gunzip < *code* | tar xfp - lecserver$ gunzip < *data* | tar xfp - lecserver$ ls -l total 3152 -r--r--r-- 1 olsona root 20768 Jan 26 10:19 africa -r--r--r-- 1 olsona root 12028 Jan 26 10:19 antarctica -r--r--r-- 1 olsona root 4094 Jan 26 10:19 asctime.c -r--r--r-- 1 olsona root 65779 Jan 30 08:59 asia -r--r--r-- 1 olsona root 55475 Jan 26 10:19 australasia -r--r--r-- 1 olsona root 3678 Jan 26 10:19 backward -r--r--r-- 1 olsona root 3417 Jan 26 10:19 checktab.awk -r--r--r-- 1 olsona root 5065 Jan 26 10:19 date.1 -rw-r--r-- 1 olsona root 6151 Jan 30 08:59 date.1.txt -r--r--r-- 1 olsona root 22986 Jan 26 10:19 date.c -r--r--r-- 1 olsona root 1708 Jan 26 10:19 difftime.c -r--r--r-- 1 olsona root 2921 Jan 26 10:19 etcetera -r--r--r-- 1 olsona root 104518 Jan 26 10:19 europe -r--r--r-- 1 olsona root 311 Jan 26 10:19 factory -r--r--r-- 1 olsona root 1273 Jan 26 10:19 ialloc.c -r--r--r-- 1 olsona root 4008 Jan 26 10:19 iso3166.tab -r--r--r-- 1 olsona root 55948 Jan 26 10:19 itca.jpg -r--r--r-- 1 olsona root 3080 Jan 26 10:19 leapseconds -r--r--r-- 1 olsona root 45789 Jan 26 10:19 localtime.c -r--r--r-- 1 olsona root 2010 Jan 26 10:19 logwtmp.c -r--r--r-- 1 olsona root 15516 Jan 26 10:19 Makefile -r--r--r-- 1 olsona root 5766 Jan 26 10:19 newctime.3 -rw-r--r-- 1 olsona root 5942 Jan 30 08:59 newctime.3.txt -r--r--r-- 1 olsona root 6732 Jan 26 10:19 newstrftime.3 -rw-r--r-- 1 olsona root 4995 Jan 30 08:59 newstrftime.3.txt -r--r--r-- 1 olsona root 5338 Jan 26 10:19 newtzset.3 -rw-r--r-- 1 olsona root 6850 Jan 30 08:59 newtzset.3.txt -r--r--r-- 1 olsona root 92970 Jan 30 08:59 northamerica -r--r--r-- 1 olsona root 1112 Jan 26 10:19 pacificnew -r--r--r-- 1 olsona root 6839 Jan 26 10:19 private.h -r--r--r-- 1 olsona root 3739 Jan 26 10:19 README -r--r--r-- 1 olsona root 1105 Jan 26 10:19 scheck.c -r--r--r-- 1 olsona root 19224 Jan 26 10:19 solar87 -r--r--r-- 1 olsona root 19242 Jan 26 10:19 solar88 -r--r--r-- 1 olsona root 19518 Jan 26 10:19 solar89 -r--r--r-- 1 olsona root 45285 Jan 26 10:19 southamerica -r--r--r-- 1 olsona root 18681 Jan 26 10:19 strftime.c -r--r--r-- 1 olsona root 1464 Jan 26 10:19 systemv -r--r--r-- 1 olsona root 24038 Jan 26 10:19 Theory -r--r--r-- 1 olsona root 3290 Jan 26 10:19 time2posix.3 -rw-r--r-- 1 olsona root 3402 Jan 30 08:59 time2posix.3.txt -rw-r--r-- 1 olsona root 0 Feb 6 10:17 typescript -r--r--r-- 1 olsona root 11956 Jan 26 10:19 tz-art.htm -r--r--r-- 1 olsona root 28222 Jan 30 08:59 tz-link.htm -rw-r--r-- 1 olsona root 180636 Feb 6 10:18 tzcode2006a.tar.gz -rw-r--r-- 1 olsona root 149612 Feb 6 10:18 tzdata2006a.tar.gz -r--r--r-- 1 olsona root 3669 Jan 26 10:19 tzfile.5 -rw-r--r-- 1 olsona root 3789 Jan 30 08:59 tzfile.5.txt -r--r--r-- 1 olsona root 4792 Jan 26 10:19 tzfile.h -r--r--r-- 1 olsona root 1100 Jan 26 10:19 tzselect.8 -rw-r--r-- 1 olsona root 1089 Jan 30 08:59 tzselect.8.txt -r--r--r-- 1 olsona root 6880 Jan 26 10:19 tzselect.ksh -r--r--r-- 1 olsona root 5839 Jan 26 10:19 usno1988 -r--r--r-- 1 olsona root 21156 Jan 26 10:19 usno1989 -r--r--r-- 1 olsona root 21154 Jan 26 10:19 usno1989a -r--r--r-- 1 olsona root 10354 Jan 26 10:19 usno1995 -r--r--r-- 1 olsona root 10405 Jan 26 10:19 usno1997 -r--r--r-- 1 olsona root 10405 Jan 26 10:19 usno1998 -r--r--r-- 1 olsona root 404 Jan 26 10:19 workman.sh -r--r--r-- 1 olsona root 610 Jan 26 10:19 yearistype.sh -r--r--r-- 1 olsona root 1365 Jan 26 10:19 zdump.8 -rw-r--r-- 1 olsona root 1449 Jan 30 08:59 zdump.8.txt -r--r--r-- 1 olsona root 15656 Jan 26 10:19 zdump.c -r--r--r-- 1 olsona root 10192 Jan 26 10:19 zic.8 -rw-r--r-- 1 olsona root 10463 Jan 30 08:59 zic.8.txt -r--r--r-- 1 olsona root 53629 Jan 26 10:19 zic.c -r--r--r-- 1 olsona root 17770 Jan 30 08:59 zone.tab lecserver$ grep -i load * date.1:UTC leap seconds are loaded from date.1.txt: are loaded from /usr/local/etc/zoneinfo/posixrules. etcetera:# as functions like gmtime load the "GMT" file to handle leap seconds properly. localtime.c:** The DST rules to use if TZ has no rules and we can't load TZDEFRULES. localtime.c:static void gmtload P((struct state * sp)); localtime.c:static int tzload P((const char * name, struct state * sp)); localtime.c:tzload(name, sp) localtime.c: register int load_result; localtime.c: load_result = tzload(TZDEFRULES, sp); localtime.c: if (load_result != 0) localtime.c: if (*name == '\0' && load_result != 0) localtime.c:gmtload(sp) localtime.c: if (tzload(gmt, sp) != 0) localtime.c: if (tzload((char *) NULL, lclptr) != 0) localtime.c: gmtload(lclptr); localtime.c: } else if (tzload(name, lclptr) != 0) localtime.c: (void) gmtload(lclptr); localtime.c: gmtload(gmtptr); newctime.3:UTC leap seconds are loaded from newctime.3.txt: are loaded from /usr/local/etc/zoneinfo/posixrules. newtzset.3:UTC leap seconds are loaded from newtzset.3.txt: are loaded from /usr/local/etc/zoneinfo/posixrules. tz-link.htm:The following shell commands download tz-link.htm:see the downloaded tz-link.htm:href="http://www.manifold.net/download/freemaps.html">Free Maps and lecserver$ exit script done on Mon 06 Feb 2006 10:18:55 AM EST ________________________________ From: Zeb Olaff [mailto:zebonebo@gmail.com] Sent: Friday, February 03, 2006 8:45 PM To: tz(a)lecserver.nci.nih.gov Subject: Misspelling With the Australia/Lord_Howe Time Zone I am using your database and have found that the full name for the Australia/Lord_Howe reads "Load Howe" instead of "Lord Howe". Hopefully this is the correct email address to send this information to. Thank You, Zeb Olaf

1 0

FW: Misspelling With the Australia/Lord_Howe Time Zone
by Olson, Arthur David (NIH/NCI) [E] Feb. 6, 2006

Feb. 6, 2006

Zeb Olaff is not on the time zone mailing list; direct replies appropriately. --ado ________________________________ From: Zeb Olaff [mailto:zebonebo@gmail.com] Sent: Friday, February 03, 2006 8:45 PM To: tz(a)lecserver.nci.nih.gov Subject: Misspelling With the Australia/Lord_Howe Time Zone I am using your database and have found that the full name for the Australia/Lord_Howe reads "Load Howe" instead of "Lord Howe". Hopefully this is the correct email address to send this information to. Thank You, Zeb Olaf

1 0

Misspelling With the Australia/Lord_Howe Time Zone
by Zeb Olaff Feb. 4, 2006

Feb. 4, 2006

I am using your database and have found that the full name for the Australia/Lord_Howe reads "Load Howe" instead of "Lord Howe". Hopefully this is the correct email address to send this information to. Thank You, Zeb Olaf

1 0

Re: FW: tzcode2006a.tar.gz on Irix 6.5.18m
by Paul Eggert Feb. 3, 2006

Feb. 3, 2006

Andrew Donaldson <A.Donaldson(a)bom.gov.au> writes: > Yell out if you would like anything else tested. Thanks for looking into the problem. There were a lot of changes between the non-working and the working zdump.c. I enclose them below. One thing that jumps out is the new setabsoletes() function. I suspect that it is not working properly on your host. Can you verify this, by using a debugger and/or inserting print statements? I would like to know the value of absolute_min_time and absolute_max_time when setabsoletes returns, and I'd also like to know the size and signedness of time_t on your host. (The code is relying on undefined behavior here, so it's not strictly portable.) Thanks. --- tz-2004gg/zdump.c 2004-10-18 08:37:53.000000000 -0700 +++ tz-2004hg/zdump.c 2004-12-07 08:40:04.000000000 -0800 @@ -1,4 +1,4 @@ -static char elsieid[] = "@(#)zdump.c 7.47"; +static char elsieid[] = "@(#)zdump.c 7.57"; /* ** This code has been made independent of the rest of the time @@ -11,6 +11,15 @@ static char elsieid[] = "@(#)zdump.c 7.4 #include "sys/types.h" /* for time_t */ #include "time.h" /* for struct tm */ #include "stdlib.h" /* for exit, malloc, atoi */ +#include "float.h" /* for FLT_MAX and DBL_MAX */ + +#ifndef ZDUMP_LO_YEAR +#define ZDUMP_LO_YEAR (-500) +#endif /* !defined ZDUMP_LO_YEAR */ + +#ifndef ZDUMP_HI_YEAR +#define ZDUMP_HI_YEAR 2500 +#endif /* !defined ZDUMP_HI_YEAR */ #ifndef MAX_STRING_LENGTH #define MAX_STRING_LENGTH 1024 @@ -71,6 +80,10 @@ static char elsieid[] = "@(#)zdump.c 7.4 #define isleap_sum(a, b) isleap((a) % 400 + (b) % 400) #endif /* !defined isleap_sum */ +#define SECSPERDAY ((long) SECSPERHOUR * HOURSPERDAY) +#define SECSPERNYEAR (SECSPERDAY * DAYSPERNYEAR) +#define SECSPERLYEAR (SECSPERNYEAR + SECSPERDAY) + #if HAVE_GETTEXT #include "locale.h" /* for setlocale */ #include "libintl.h" @@ -127,13 +140,18 @@ extern char * optarg; extern int optind; extern char * tzname[2]; +static time_t absolute_min_time; +static time_t absolute_max_time; +static size_t longest; +static char * progname; + static char * abbr P((struct tm * tmp)); static long delta P((struct tm * newp, struct tm * oldp)); +static void dumptime P((const struct tm * tmp)); static time_t hunt P((char * name, time_t lot, time_t hit)); -static size_t longest; -static char * progname; +static void setabsolutes(); static void show P((char * zone, time_t t, int v)); -static void dumptime P((const struct tm * tmp)); +static time_t yeartot P((long y)); int main(argc, argv) @@ -143,18 +161,22 @@ char * argv[]; register int i; register int c; register int vflag; - register char * cutoff; - register int cutyear; - register long cuttime; - char ** fakeenv; + register char * cutarg; + register long cutloyear = ZDUMP_LO_YEAR; + register long cuthiyear = ZDUMP_HI_YEAR; + register time_t cutlotime; + register time_t cuthitime; + register char ** fakeenv; time_t now; time_t t; time_t newt; - time_t hibit; struct tm tm; struct tm newtm; + register struct tm * tmp; + register struct tm * newtmp; - INITIALIZE(cuttime); + INITIALIZE(cutlotime); + INITIALIZE(cuthitime); #if HAVE_GETTEXT (void) setlocale(LC_MESSAGES, ""); #ifdef TZ_DOMAINDIR @@ -169,34 +191,45 @@ char * argv[]; (void) exit(EXIT_SUCCESS); } vflag = 0; - cutoff = NULL; + cutarg = NULL; while ((c = getopt(argc, argv, "c:v")) == 'c' || c == 'v') if (c == 'v') vflag = 1; - else cutoff = optarg; + else cutarg = optarg; if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { (void) fprintf(stderr, -_("%s: usage is %s [ --version ] [ -v ] [ -c cutoff ] zonename ...\n"), - argv[0], argv[0]); +_("%s: usage is %s [ --version ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n"), + progname, progname); + (void) exit(EXIT_FAILURE); + } + if (vflag) { + if (cutarg != NULL) { + long lo; + long hi; + char c; + + if (sscanf(cutarg, "%ld%c", &hi, &c) == 1) { + cuthiyear = hi; + } else if (sscanf(cutarg, "%ld,%ld%c", + &lo, &hi, &c) == 2) { + cutloyear = lo; + cuthiyear = hi; + } else { +(void) fprintf(stderr, _("%s: wild -c argument %s\n"), + progname, cutarg); (void) exit(EXIT_FAILURE); } - if (cutoff != NULL) { - int y; - - cutyear = atoi(cutoff); - cuttime = 0; - for (y = EPOCH_YEAR; y < cutyear; ++y) - cuttime += DAYSPERNYEAR + isleap(y); - cuttime *= SECSPERHOUR * HOURSPERDAY; + } + setabsolutes(); + cutlotime = yeartot(cutloyear); + cuthitime = yeartot(cuthiyear); } (void) time(&now); longest = 0; for (i = optind; i < argc; ++i) if (strlen(argv[i]) > longest) longest = strlen(argv[i]); - for (hibit = 1; (hibit << 1) != 0; hibit <<= 1) - continue; { register int from; register int to; @@ -226,58 +259,129 @@ _("%s: usage is %s [ --version ] [ -v ] show(argv[i], now, FALSE); continue; } - /* - ** Get lowest value of t. - */ - t = hibit; - if (t > 0) /* time_t is unsigned */ - t = 0; + t = absolute_min_time; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); - tm = *localtime(&t); + if (t < cutlotime) + t = cutlotime; + tmp = localtime(&t); + if (tmp != NULL) { + tm = *tmp; (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); + } for ( ; ; ) { - if (cutoff != NULL && t >= cuttime) + if (t >= cuthitime) break; newt = t + SECSPERHOUR * 12; - if (cutoff != NULL && newt >= cuttime) + if (newt >= cuthitime) break; if (newt <= t) break; - newtm = *localtime(&newt); - if (delta(&newtm, &tm) != (newt - t) || + newtmp = localtime(&newt); + if (newtmp != NULL) + newtm = *newtmp; + if ((tmp == NULL || newtmp == NULL) ? (tmp != newtmp) : + (delta(&newtm, &tm) != (newt - t) || newtm.tm_isdst != tm.tm_isdst || - strcmp(abbr(&newtm), buf) != 0) { + strcmp(abbr(&newtm), buf) != 0)) { newt = hunt(argv[i], t, newt); - newtm = *localtime(&newt); - (void) strncpy(buf, abbr(&newtm), + newtmp = localtime(&newt); + if (newtmp != NULL) { + newtm = *newtmp; + (void) strncpy(buf, + abbr(&newtm), (sizeof buf) - 1); } + } t = newt; tm = newtm; + tmp = newtmp; } - /* - ** Get highest value of t. - */ - t = ~((time_t) 0); - if (t < 0) /* time_t is signed */ - t &= ~hibit; + t = absolute_max_time; t -= SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); } if (fflush(stdout) || ferror(stdout)) { - (void) fprintf(stderr, "%s: ", argv[0]); + (void) fprintf(stderr, "%s: ", progname); (void) perror(_("Error writing standard output")); (void) exit(EXIT_FAILURE); } exit(EXIT_SUCCESS); + /* If exit fails to exit... */ + return EXIT_FAILURE; +} - /* gcc -Wall pacifier */ - for ( ; ; ) +static void +setabsolutes() +{ + if (0.5 == (time_t) 0.5) { + /* + ** time_t is floating. + */ + if (sizeof (time_t) == sizeof (float)) { + absolute_min_time = (time_t) -FLT_MAX; + absolute_max_time = (time_t) FLT_MAX; + } else if (sizeof (time_t) == sizeof (double)) { + absolute_min_time = (time_t) -DBL_MAX; + absolute_max_time = (time_t) DBL_MAX; + } else { + (void) fprintf(stderr, +_("%s: use of -v on system with floating time_t other than float or double\n"), + progname); + (void) exit(EXIT_FAILURE); + } + } else if (0 > (time_t) -1) { + /* + ** time_t is signed. + */ + register time_t hibit; + + for (hibit = 1; (hibit * 2) != 0; hibit *= 2) continue; + absolute_min_time = hibit; + absolute_max_time = -(hibit + 1); + } else { + /* + ** time_t is unsigned. + */ + absolute_min_time = 0; + absolute_max_time = absolute_min_time - 1; + } +} + +static time_t +yeartot(y) +const long y; +{ + register long myy; + register long seconds; + register time_t t; + + myy = EPOCH_YEAR; + t = 0; + while (myy != y) { + if (myy < y) { + seconds = isleap(myy) ? SECSPERLYEAR : SECSPERNYEAR; + ++myy; + if (t > absolute_max_time - seconds) { + t = absolute_max_time; + break; + } + t += seconds; + } else { + --myy; + seconds = isleap(myy) ? SECSPERLYEAR : SECSPERNYEAR; + if (t < absolute_min_time + seconds) { + t = absolute_min_time; + break; + } + t -= seconds; + } + } + return t; } static time_t @@ -287,24 +391,38 @@ time_t lot; time_t hit; { time_t t; + long diff; struct tm lotm; + register struct tm * lotmp; struct tm tm; - static char loab[MAX_STRING_LENGTH]; + register struct tm * tmp; + char loab[MAX_STRING_LENGTH]; - lotm = *localtime(&lot); + lotmp = localtime(&lot); + if (lotmp != NULL) { + lotm = *lotmp; (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); - while ((hit - lot) >= 2) { - t = lot / 2 + hit / 2; + } + for ( ; ; ) { + diff = (long) (hit - lot); + if (diff < 2) + break; + t = lot; + t += diff / 2; if (t <= lot) ++t; else if (t >= hit) --t; - tm = *localtime(&t); - if (delta(&tm, &lotm) == (t - lot) && + tmp = localtime(&t); + if (tmp != NULL) + tm = *tmp; + if ((lotmp == NULL || tmp == NULL) ? (lotmp == tmp) : + (delta(&tm, &lotm) == (t - lot) && tm.tm_isdst == lotm.tm_isdst && - strcmp(abbr(&tm), loab) == 0) { + strcmp(abbr(&tm), loab) == 0)) { lot = t; lotm = tm; + lotmp = tmp; } else hit = t; } show(name, lot, TRUE); @@ -321,8 +439,8 @@ delta(newp, oldp) struct tm * newp; struct tm * oldp; { - long result; - int tmy; + register long result; + register int tmy; if (newp->tm_year < oldp->tm_year) return -delta(oldp, newp); @@ -345,15 +463,22 @@ char * zone; time_t t; int v; { - struct tm * tmp; + register struct tm * tmp; (void) printf("%-*s ", (int) longest, zone); if (v) { - dumptime(gmtime(&t)); - (void) printf(" UTC = "); + tmp = gmtime(&t); + if (tmp == NULL) { + (void) printf("%g", (double) t); + } else { + dumptime(tmp); + (void) printf(" UTC"); + } + (void) printf(" = "); } tmp = localtime(&t); dumptime(tmp); + if (tmp != NULL) { if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); if (v) { @@ -362,6 +487,7 @@ int v; (void) printf(" gmtoff=%ld", tmp->TM_GMTOFF); #endif /* defined TM_GMTOFF */ } + } (void) printf("\n"); } @@ -394,6 +520,10 @@ register const struct tm * timeptr; register int lead; register int trail; + if (timeptr == NULL) { + (void) printf("NULL"); + return; + } /* ** The packaged versions of localtime and gmtime never put out-of-range ** values in tm_wday or tm_mon, but since this code might be compiled

1 0

FW: Time zone error for US cities.
by Olson, Arthur David (NIH/NCI) [E] Feb. 2, 2006

Feb. 2, 2006

Jian Zhang is not on the time zone mailling list; direct replies appropriately. --ado ________________________________ From: Jian Zhang [mailto:Jian.Zhang@Campbell.com] Sent: Wednesday, February 01, 2006 3:26 PM To: tz(a)lecserver.nci.nih.gov Subject: Time zone error for US cities. Dear Sir/Madam, I am trying to use the Time zone converter and got an error for US cities. The error is: When I try to convert the New_York time from: 30-Apr-1972 02:10:30 To GMT time, it gives me the time as: 31-Dec-1969 23:59:59 That is clearly wrong. Does any one have the same problem? The error is isolated to the 02:00:00 to 03:00:00 on that date. Thanks Email jian.zhang(a)campbell.com Jian ______________________________________________________________________ Campbell & Company, Inc.: The information in this e-mail may contain privileged/confidential information. If you are not the intended recipient, you must not read, use, copy or disseminate the information or take any action in reliance thereupon. If you have received this e-mail in error, please notify Campbell & Company, Inc. immediately by e-mail or telephone and delete the e-mail and any attachments from any computer. The information in this e-mail does not constitute an offer to sell or the solicitation of an offer to buy any securities in any jurisdiction or for the benefit of any person. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 1

FW: tzcode2006a.tar.gz on Irix 6.5.18m
by Olson, Arthur David (NIH/NCI) [E] Feb. 2, 2006

Feb. 2, 2006

Andrew Donaldson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Andrew Donaldson [mailto:A.Donaldson@bom.gov.au] Sent: Wednesday, February 01, 2006 10:48 PM To: tz(a)lecserver.nci.nih.gov Cc: Rob Petrini Subject: tzcode2006a.tar.gz on Irix 6.5.18m Dear Sir, We had just had reason to update some of our SGI machines' timezone data to reflect the changes in Melbourne, Australia due to the Commonwealth Games. Please note that we are hardly experts in this area, so we may have missed something obvious. We found that the zdump utility, used with the -v option, would only output the first times. $ ./zdump -v Australia/Melbourne Australia/Melbourne Thu Jan 1 00:00:00 1970 UTC = Thu Jan 1 10:00:00 1970 EST isdst=0 Australia/Melbourne Fri Jan 2 00:00:00 1970 UTC = Fri Jan 2 10:00:00 1970 EST isdst=0 Australia/Melbourne Tue Dec 30 23:59:59 1969 UTC = Wed Dec 31 09:59:59 1969 EST isdst=0 Australia/Melbourne Wed Dec 31 23:59:59 1969 UTC = Thu Jan 1 09:59:59 1970 EST isdst=0 After a bit of head scratching, we proved that the data files were valid, by viewing them on a linux computer, so we tried the source code from the classictzcode.tar.gz file which produced valid results both with the classictzdata.tar.gz and tzdata2006a.tar.gz data, the later including the updates to Melbourne time that we desired. I am unsure why the tzcode2006a.tar.gz version of zdump behaved differently. To compile tzcode2006a.tar.gz I had to make these changes: $ diff localtime.c localtime.c.orig 512d511 < /* 517,518d515 < */ < const char * getqzname P((const char * strp, const char delim)) To compile classictzcode.tar.gz I had to make these changes: $ diff zic.c zic.c.orig 64,65c64 < /*extern int getopt P((int argc, char * argv[], const char * options));*/ < extern int getopt P((int, char *const *, const char *)); --- > extern int getopt P((int argc, char * argv[], const char * options)); and $ diff getopt.c getopt.c.orig 52d51 < /* 57,58d55 < */ < int getopt(int nargc, char *const *nargv, const char *ostr) I hope our findings are useful to you. regards, Andrew Donaldson.

2 1

Bug#351049: libc6: America/Havana DST info wrong for 2005/2006
by Lionel Elie Mamane Feb. 2, 2006

Feb. 2, 2006

Package: libc6 Version: 2.3.5-12.1 Severity: normal Cuba did not switch back to non-DST time on October 2005, but the timezone info in libc thinks it did: Rule Cuba 2005 max - Oct lastSun 0:00s 0 S That line should probably be changed to Rule Cuba 2006 max - Oct lastSun 0:00s 0 S Source: http://www.timeanddate.com/worldclock/timezone.html?n=99 (and a friend that spent vacation in Cuba) Note that the timezone/northamerica says: # From Evert van der Veer via Steffen Thorsen (2004-10-28): # Cuba is not going back to standard time this year. # From Paul Eggert (2004-10-28): # http://www.granma.cu/ingles/2004/septiembre/juev30/41medid-i.html # says that it's due to a problem at the Antonio Guiteras # thermoelectric plant, and says "This October there will be no return # to normal hours (after daylight saving time)". # For now, let's assume that it's a one-year temporary measure. ^^^^^^^^^^^^^^^^^^^^^^^^^ So it became a two-year temporary measure? We are not sure if it won't become a 3+ year temporary measure. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-deb1-64bit Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) -- no debconf information

1 0

tzcode2006a.tar.gz on Irix 6.5.18m
by Andrew Donaldson Feb. 2, 2006

Feb. 2, 2006

Dear Sir, We had just had reason to update some of our SGI machines' timezone data to reflect the changes in Melbourne, Australia due to the Commonwealth Games. Please note that we are hardly experts in this area, so we may have missed something obvious. We found that the zdump utility, used with the -v option, would only output the first times. $ ./zdump -v Australia/Melbourne Australia/Melbourne Thu Jan 1 00:00:00 1970 UTC = Thu Jan 1 10:00:00 1970 EST isdst=0 Australia/Melbourne Fri Jan 2 00:00:00 1970 UTC = Fri Jan 2 10:00:00 1970 EST isdst=0 Australia/Melbourne Tue Dec 30 23:59:59 1969 UTC = Wed Dec 31 09:59:59 1969 EST isdst=0 Australia/Melbourne Wed Dec 31 23:59:59 1969 UTC = Thu Jan 1 09:59:59 1970 EST isdst=0 After a bit of head scratching, we proved that the data files were valid, by viewing them on a linux computer, so we tried the source code from the classictzcode.tar.gz file which produced valid results both with the classictzdata.tar.gz and tzdata2006a.tar.gz data, the later including the updates to Melbourne time that we desired. I am unsure why the tzcode2006a.tar.gz version of zdump behaved differently. To compile tzcode2006a.tar.gz I had to make these changes: $ diff localtime.c localtime.c.orig 512d511 < /* 517,518d515 < */ < const char * getqzname P((const char * strp, const char delim)) To compile classictzcode.tar.gz I had to make these changes: $ diff zic.c zic.c.orig 64,65c64 < /*extern int getopt P((int argc, char * argv[], const char * options));*/ < extern int getopt P((int, char *const *, const char *)); --- > extern int getopt P((int argc, char * argv[], const char * options)); and $ diff getopt.c getopt.c.orig 52d51 < /* 57,58d55 < */ < int getopt(int nargc, char *const *nargv, const char *ostr) I hope our findings are useful to you. regards, Andrew Donaldson.

1 0

Time zone error for US cities.
by Jian Zhang Feb. 1, 2006

Feb. 1, 2006

Dear Sir/Madam, I am trying to use the Time zone converter and got an error for US cities. The error is: When I try to convert the New_York time from: 30-Apr-1972 02:10:30 To GMT time, it gives me the time as: 31-Dec-1969 23:59:59 That is clearly wrong. Does any one have the same problem? The error is isolated to the 02:00:00 to 03:00:00 on that date. Thanks Email jian.zhang(a)campbell.com Jian ______________________________________________________________________ Campbell & Company, Inc.: The information in this e-mail may contain privileged/confidential information. If you are not the intended recipient, you must not read, use, copy or disseminate the information or take any action in reliance thereupon. If you have received this e-mail in error, please notify Campbell & Company, Inc. immediately by e-mail or telephone and delete the e-mail and any attachments from any computer. The information in this e-mail does not constitute an offer to sell or the solicitation of an offer to buy any securities in any jurisdiction or for the benefit of any person. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

1 0

The 2003 North Dakota change
by Andy Lipscomb Jan. 31, 2006

Jan. 31, 2006

The largest city by far in either county is Mandan, but the report indicates they were already on Central time. Next largest, at a whopping 897 population, is New Salem. The only source of data I've found on that town is hometownlocator.com, which reports it to be at 46.845N and 101.41083W (the Census Bureau's TIGER mapper confirms that point is in the city, though not quite the center). That converts to DMS as +465042-1012439, yielding LMT of-6:45:39. If New Salem is also in the already-Central section (I suspect it is not, since it's a true rural area, and Mandan is the western part of Bismarck), next largest is Glen Ullin, at +464854-1014946 and an LMT of -6:47:19.

1 0

tzcode2006a.tar.gz and tzdata2006a.tar.gz
by Arthur David Olson Jan. 30, 2006

Jan. 30, 2006

The files ftp://elsie.nci.nih.gov/pub/tzcode2006a.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2006a.tar.gz are now available. These reflect the changes circulated on the time zone mailing list on 2006-01-20 by Paul Eggert (in particular, Indiana time zone moves); they also reflect an addition to the zic manual page to describe how special-case transitions are handled. The versions above do NOT reflect 64-bit changes; the current (unchanged) plan is for those changes to show up on U. S. Presidents' Day (2006-02-20). --ado

1 0

Upcoming Indiana time zone moves
by Arthur David Olson Jan. 30, 2006

Jan. 30, 2006

My current sense: in the absence of clarification from the United States Department of Transportation (DOT), the way to proceed with the upcoming Indiana time zone moves is to handle them as direct transitions from Eastern Standard Time to Central Daylight Time (without wall clock changes). 1. This reflects what's happened historically in other places. 2. This reflects what I'd expect to happen in reality in Indiana-- folks in the affected areas will not change their clocks. 3. This reflects presumed regulatory intent. Given the peculiar characteristics of the particular second DOT chose for the transition, and the overwhelmingly larger number of seconds in a year, I believe it highly likely that DOT's choice was made with the intent of allowing the transition to occur without clocks changing. Also, there's no mention in the DOT docket of the need for changing clocks twice. I've attached changes to the "zic" manual page that document the reprogramming done back in the year 1996 to do direct transitions; the changes also provide information on how to get (very close to) a one-hour retreat followed one hour later by a one-hour advance. Since the affected regions will spend an hour in a nether-region between CDT and EST, perhaps a special time zone abbreviation is needed. The only letter between C and E is D: "Decidedly Odd Time" (DOT) :-) --ado ------- zic.8 ------- *** /tmp/geta8763 Tue Jan 24 12:03:21 2006 --- /tmp/getb8763 Tue Jan 24 12:03:21 2006 *************** *** 411,424 **** .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTE For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.22 --- 411,444 ---- .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTES For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. + .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving + coincides with and is equal to + a clock retreat caused by a change in UTC offset, + .IR zic + produces a single transition to daylight saving at the new UTC offset + (without any change in wall clock time). + If you want two separate transitions + (for example, + a one-hour retreat from + U. S. Eastern Standard Time + to + U. S. Central Standard Time + followed one hour later by a one-hour advance to + U. S. Central Daylight Time), + you can artificially + (and slightly inaccurately) + specify the UTC offset change as occuring a single second too early. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.23

3 3

Re: Upcoming Indiana time zone moves
by Arthur David Olson Jan. 26, 2006

Jan. 26, 2006

No news from DOT this morning. With Paul Eggert's technique in mind, below find a revised patch to the zic manual page. Barring new developments, on Monday I'll incorporate the manual changes and Paul's previously circulated data changes into the ftp version. --ado ------- zic.8 ------- *** /tmp/geta14571 Thu Jan 26 09:15:18 2006 --- /tmp/getb14571 Thu Jan 26 09:15:18 2006 *************** *** 411,424 **** .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTE For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.22 --- 411,436 ---- .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTES For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. + .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving + coincides with and is equal to + a clock retreat caused by a change in UTC offset, + .IR zic + produces a single transition to daylight saving at the new UTC offset + (without any change in wall clock time). + To get separate transitions + use multiple zone continuation lines + specifying transition instants using universal time. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.24

2 1

RE: Upcoming Indiana time zone moves
by Olson, Arthur David (NIH/NCI) [E] Jan. 26, 2006

Jan. 26, 2006

When a mountain-to-central change occurs as DST ends, the destination (central) time zone is already out of DST at the instant when the transition occurs; things get handled correctly without any special casing (take America/North_Dakota/Center, please.) --ado -----Original Message----- From: Andy Lipscomb [mailto:AndyLipscomb@decosimo.com] Sent: Thursday, January 26, 2006 10:03 AM To: tz(a)lecserver.nci.nih.gov Subject: RE: Upcoming Indiana time zone moves + .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving coincides with + and is equal to a clock retreat caused by a change in UTC offset, .IR + zic produces a single transition to daylight saving at the new UTC + offset (without any change in wall clock time). Can this be implemented also for the opposite case (daylight savings ends, but the offset is advanced)? This was the case with the M->C changes in the Dakotas.

1 0

RE: Upcoming Indiana time zone moves
by Andy Lipscomb Jan. 26, 2006

Jan. 26, 2006

+ .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving coincides with + and is equal to a clock retreat caused by a change in UTC offset, .IR + zic produces a single transition to daylight saving at the new UTC + offset (without any change in wall clock time). Can this be implemented also for the opposite case (daylight savings ends, but the offset is advanced)? This was the case with the M->C changes in the Dakotas.

1 0

proposed tz patches for Indiana, New Brunswick, Gaza, etc.
by Paul Eggert Jan. 26, 2006

Jan. 26, 2006

Here are some proposed changes to the tz database reflecting the recent flurry of email about Indiana, along with other news about New Brunswick and Gaza, and other less-important changes that I've been saving up. Changes to the tz data. * Create a new zone America/Indiana/Petersburg for Pike County, Indiana, which moved from central to eastern time in 1977. Thanks to Gwillim Law for the heads-up. * Adjust America/Indiana/Petersburg and America/Indiana/Knox, since Pike and Starke Counties will switch to CST in April. Create a new Zone America/Indiana/Vincennes for Daviess, Dubois, Knox, Martin, Perry, and Pulaski Counties, Indiana, which will also switch. Thanks to Deborah Goldsmith for the DOT news. * Create a new zone America/Moncton for New Brunswick, which recently announced that it will follow the new US rules in 2007. New Brunswick switches at 00:01, not 02:00, so it needs a separate zone. * In October 2005 Gaza switched at 02:00, not 01:00. Thanks to Steffen Thorsen for this info. Commentary fixes only. * Note that we don't have the data yet for the 2003-10-26 time zone change in Morton and Sioux Counties, North Dakota. Thanks to Gwillim Law for the heads-up. * Identify which Michigan counties were affected by the 1973 change. Thanks to Gwillim Law for the info. * Clinton and Russell Counties, Kentucky, were incorrectly referred to in a comment. Minor changes to rules that don't affect behavior. * Sort the Halifax rules by date, and use the same tabbing scheme as elsewhere. Fixes to the web page. * Mention the proposed IANA Time Zone Registry. * Mention iCalendar Basic. * Mention TZInfo, a new Ruby-based tz compiler. * Update references to Indiana, to reflect the recent changes. * Add a reference to Shanks's new edition (not yet available). * Add a reference to Steve Allen's fine Time Scales web page. * Add a reference to LeapSecond.com. * Mention the XML schema for date and time formats, and add a reference to Date & Time Formats on the Web. * Update URLs to reflect moved web pages. =================================================================== RCS file: RCS/asia,v retrieving revision 2005.18 retrieving revision 2005.18.0.1 diff -pu -r2005.18 -r2005.18.0.1 --- asia 2005/12/22 14:31:14 2005.18 +++ asia 2006/01/20 22:34:20 2005.18.0.1 @@ -934,6 +934,10 @@ Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 3 # From Paul Eggert (2005-11-22): # Starting 2003 transitions are from Steffen Thorsen's web site timeanddate.com. # +# From Steffen Thorsen (2005-11-23): +# For Jordan I have received multiple independent user reports every year +# about DST end dates, as the end-rule is different every year. +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Jordan 1973 only - Jun 6 0:00 1:00 S Rule Jordan 1973 1975 - Oct 1 0:00 0 - @@ -1433,6 +1437,12 @@ Zone Asia/Karachi 4:28:12 - LMT 1907 # From Paul Eggert (2005-11-22): # Starting 2004 transitions are from Steffen Thorsen's web site timeanddate.com. +# From Steffen Thorsen (2005-11-23): +# A user from Gaza reported that Gaza made the change early because of +# the Ramadan. Next year Ramadan will be even earlier, so I think +# there is a good chance next year's end date will be around two weeks +# earlier--the same goes for Jordan. + # The rules for Egypt are stolen from the `africa' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule EgyptAsia 1957 only - May 10 0:00 1:00 S @@ -1445,7 +1455,7 @@ Rule EgyptAsia 1966 only - Oct 1 3:00 0 Rule Palestine 1999 max - Apr Fri>=15 0:00 1:00 S Rule Palestine 1999 2003 - Oct Fri>=15 0:00 0 - Rule Palestine 2004 only - Oct 1 1:00 0 - -Rule Palestine 2005 max - Oct 4 1:00 0 - +Rule Palestine 2005 max - Oct 4 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct =================================================================== RCS file: RCS/northamerica,v retrieving revision 2005.16 retrieving revision 2005.16.0.1 diff -pu -r2005.16 -r2005.16.0.1 --- northamerica 2005/12/27 14:26:54 2005.16 +++ northamerica 2006/01/20 22:34:20 2005.16.0.1 @@ -321,6 +321,14 @@ Zone America/Chicago -5:50:36 - LMT 1883 Zone America/North_Dakota/Center -6:45:12 - LMT 1883 Nov 18 12:14:48 -7:00 US M%sT 1992 Oct 25 02:00 -6:00 US C%sT +# From Paul Eggert (2006-01-20): +# The following is not implemented yet. +# What is the most populous city in that area? +# From http://www.statoids.com/tus.html (2006-01-20): +# 2003-10-26 02:00: All of Morton County, ND, and the part of Sioux +# County, ND east of ND route 31 moved from MT to CT. (The area +# around Fort Yates in Sioux County and the area around Mandan in +# Morton County were already in CT.) # US mountain time, represented by Denver # @@ -519,9 +527,9 @@ Zone America/Boise -7:44:49 - LMT 1883 N # For a map of Indiana's time zone regions, see: # <a href="http://www.mccsc.edu/time.html"> # What time is it in Indiana? -# </a> (2005-05-03) +# </a> (2005-10-30) # -# From Paul Eggert (2005-08-22): +# From Paul Eggert (2006-01-20): # Since 1970, most of Indiana has been like America/Indiana/Indianapolis, # with the following exceptions: # @@ -533,11 +541,14 @@ Zone America/Boise -7:44:49 - LMT 1883 N # - Clark, Floyd, and Harrison counties have been like # America/Kentucky/Louisville. # -# - Crawford, Starke, and Switzerland counties have their own time zone +# - Daviess, Dubois, Knox, Martin, Perry, and Pulaski counties +# have been like America/Indiana/Vincennes. +# +# - Crawford, Pike, Starke, and Switzerland counties have their own time zone # histories as noted below. # -# Shanks partitions Indiana into 345 regions, each with its own time history, -# and writes ``Even newspaper reports present contradictory information.'' +# Shanks partitioned Indiana into 345 regions, each with its own time history, +# and wrote ``Even newspaper reports present contradictory information.'' # Fortunately, most of the complexity occurred before our cutoff date of 1970. # # Other than Indianapolis, the Indiana place names are so nondescript @@ -545,11 +556,19 @@ Zone America/Boise -7:44:49 - LMT 1883 N # So we reluctantly put them all in a subdirectory `America/Indiana'. # From Paul Eggert (2005-08-16): -# http://www.mccsc.edu/time.html says that Indiana will use DST starting 2006, -# and that many counties may switch either to Central or to Eastern time. -# The county-by-county decisions have not been made yet, so for now assume -# that no counties will switch: this assumption is most likely wrong, -# but it's the best we can do for now. +# http://www.mccsc.edu/time.html says that Indiana will use DST starting 2006. + +# From Deborah Goldsmith (2006-01-18): +# http://dmses.dot.gov/docimages/pdf95/382329_web.pdf +# From Paul Eggert (2006-01-20): +# It says "DOT is relocating the time zone boundary in Indiana to move Starke, +# Pulaski, Knox, Daviess, Martin, Pike, Dubois, and Perry Counties from the +# Eastern Time Zone to the Central Time Zone.... The effective date of +# this rule is 2:OO a.m. EST Sunday, April 2, 2006, which is the +# changeover date from standard time to Daylight Saving Time." +# Strictly speaking, this means the affected counties will change their +# clocks twice that night, but this obviously is in error. The intent +# is that 01:59:59 EST be followed by 02:00:00 CDT. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Indianapolis 1941 only - Jun 22 2:00 1:00 D @@ -568,8 +587,8 @@ Zone America/Indiana/Indianapolis -5:44: -5:00 - EST 2006 -5:00 US E%sT # -# Part of Crawford County, Indiana, last observed DST in 1975, -# and left its clocks alone in 1974. +# Eastern Crawford County, Indiana, left its clocks alone in 1974, +# as well as from 1976 through 2005. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Marengo 1951 only - Apr lastSun 2:00 1:00 D Rule Marengo 1951 only - Sep lastSun 2:00 0 S @@ -586,7 +605,45 @@ Zone America/Indiana/Marengo -5:45:23 - -5:00 - EST 2006 -5:00 US E%sT # -# Starke County, Indiana +# Daviess, Dubois, Knox, Martin, Perry, and Pulaski Counties, Indiana, +# switched from eastern to central time in April 2006. +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER +Rule Vincennes 1946 only - Apr lastSun 2:00 1:00 D +Rule Vincennes 1946 only - Sep lastSun 2:00 0 S +Rule Vincennes 1953 1954 - Apr lastSun 2:00 1:00 D +Rule Vincennes 1953 1959 - Sep lastSun 2:00 0 S +Rule Vincennes 1955 only - May 1 0:00 1:00 D +Rule Vincennes 1956 1963 - Apr lastSun 2:00 1:00 D +Rule Vincennes 1960 only - Oct lastSun 2:00 0 S +Rule Vincennes 1961 only - Sep lastSun 2:00 0 S +Rule Vincennes 1962 1963 - Oct lastSun 2:00 0 S +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Indiana/Vincennes -5:50:07 - LMT 1883 Nov 18 12:09:53 + -6:00 US C%sT 1946 + -6:00 Vincennes C%sT 1964 Apr 26 2:00 + -5:00 - EST 1969 + -5:00 US E%sT 1971 + -5:00 - EST 2006 Apr 2 2:00 + -6:00 US C%sT +# +# Pike County, Indiana moved from central to eastern time in 1977, +# then switched back in 2006. +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER +Rule Pike 1955 only - May 1 0:00 1:00 D +Rule Pike 1955 1960 - Sep lastSun 2:00 0 S +Rule Pike 1956 1964 - Apr lastSun 2:00 1:00 D +Rule Pike 1961 1964 - Oct lastSun 2:00 0 S +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Indiana/Petersburg -5:49:07 - LMT 1883 Nov 18 12:10:53 + -6:00 US C%sT 1955 + -6:00 Pike C%sT 1965 Apr 25 2:00 + -5:00 - EST 1966 Oct 30 2:00 + -6:00 US C%sT 1977 Oct 30 2:00 + -5:00 - EST 2006 Apr 2 2:00 + -6:00 US C%sT +# +# Starke County, Indiana moved from central to eastern time in 1991, +# then switched back in 2006. # From Arthur David Olson (1991-10-28): # An article on page A3 of the Sunday, 1991-10-27 Washington Post # notes that Starke County switched from Central time to Eastern time as of @@ -603,10 +660,10 @@ Zone America/Indiana/Knox -5:46:30 - LMT -6:00 Starke C%sT 1962 Apr 29 2:00 -5:00 - EST 1963 Oct 27 2:00 -6:00 US C%sT 1991 Oct 27 2:00 - -5:00 - EST 2006 - -5:00 US E%sT + -5:00 - EST 2006 Apr 2 2:00 + -6:00 US C%sT # -# Switzerland County, Indiana, last observed DST in 1972. +# Switzerland County, Indiana, did not observe DST from 1973 through 2005. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Vevay -5:40:16 - LMT 1883 Nov 18 12:19:44 -6:00 US C%sT 1954 Apr 25 2:00 @@ -636,7 +693,7 @@ Zone America/Kentucky/Louisville -5:43:0 -6:00 1:00 CDT 1974 Oct 27 2:00 -5:00 US E%sT # -# Wayne, Clinton, and Russell Counties, Kentucky +# Wayne County, Kentucky # # From # <a href="http://www.lake-cumberland.com/life/archive/news990129time.shtml"> @@ -733,7 +790,8 @@ Zone America/Detroit -5:32:11 - LMT 1905 -5:00 - EST 1975 Apr 27 2:00 -5:00 US E%sT # -# The Michigan border with Wisconsin switched from EST to CST/CDT in 1973. +# Dickinson, Gogebic, Iron, and Menominee Counties, Michigan, +# switched from EST to CST/CDT in 1973. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Menominee 1946 only - Apr lastSun 2:00 1:00 D Rule Menominee 1946 only - Sep lastSun 2:00 0 S @@ -929,7 +987,7 @@ Zone America/Goose_Bay -4:01:40 - LMT 18 -4:00 StJohns A%sT -# west Labrador, New Brunswick, Nova Scotia, Prince Edward I +# west Labrador, Nova Scotia, Prince Edward I # From Paul Eggert (1996-06-12): # Shanks writes that since 1970 most of this region has been like Halifax. @@ -938,53 +996,48 @@ Zone America/Goose_Bay -4:01:40 - LMT 18 # Shanks also writes that Liverpool, NS was the only town in Canada to observe # DST in 1971 but not 1970; for now we'll assume this is a typo. -# From Paul Eggert (2000-10-02): -# INMS (2000-09-12) says that, since 1988 at least, New Brunswick switches -# at 00:01 local time. FIXME: verify and create a new Zone for this. - - # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Halifax 1916 only - Apr 1 0:00 1:00 D -Rule Halifax 1916 only - Oct 1 0:00 0 S -Rule Halifax 1920 only - May 9 0:00 1:00 D -Rule Halifax 1920 only - Aug 29 0:00 0 S -Rule Halifax 1921 only - May 6 0:00 1:00 D -Rule Halifax 1921 1922 - Sep 5 0:00 0 S -Rule Halifax 1922 only - Apr 30 0:00 1:00 D -Rule Halifax 1923 1925 - May Sun>=1 0:00 1:00 D -Rule Halifax 1923 only - Sep 4 0:00 0 S -Rule Halifax 1924 only - Sep 15 0:00 0 S -Rule Halifax 1925 only - Sep 28 0:00 0 S -Rule Halifax 1926 only - May 16 0:00 1:00 D -Rule Halifax 1926 only - Sep 13 0:00 0 S -Rule Halifax 1927 only - May 1 0:00 1:00 D -Rule Halifax 1927 only - Sep 26 0:00 0 S -Rule Halifax 1928 1931 - May Sun>=8 0:00 1:00 D -Rule Halifax 1928 only - Sep 9 0:00 0 S -Rule Halifax 1929 only - Sep 3 0:00 0 S -Rule Halifax 1930 only - Sep 15 0:00 0 S -Rule Halifax 1931 1932 - Sep Mon>=24 0:00 0 S -Rule Halifax 1932 only - May 1 0:00 1:00 D -Rule Halifax 1933 only - Apr 30 0:00 1:00 D -Rule Halifax 1933 only - Oct 2 0:00 0 S -Rule Halifax 1934 only - May 20 0:00 1:00 D -Rule Halifax 1934 only - Sep 16 0:00 0 S -Rule Halifax 1935 only - Jun 2 0:00 1:00 D -Rule Halifax 1935 only - Sep 30 0:00 0 S -Rule Halifax 1936 only - Jun 1 0:00 1:00 D -Rule Halifax 1936 only - Sep 14 0:00 0 S -Rule Halifax 1937 1938 - May Sun>=1 0:00 1:00 D -Rule Halifax 1937 1941 - Sep Mon>=24 0:00 0 S -Rule Halifax 1939 only - May 28 0:00 1:00 D -Rule Halifax 1940 1941 - May Sun>=1 0:00 1:00 D -Rule Halifax 1946 1949 - Sep lastSun 2:00 0 S -Rule Halifax 1946 1949 - Apr lastSun 2:00 1:00 D -Rule Halifax 1951 1954 - Sep lastSun 2:00 0 S -Rule Halifax 1951 1954 - Apr lastSun 2:00 1:00 D -Rule Halifax 1956 1959 - Sep lastSun 2:00 0 S -Rule Halifax 1956 1959 - Apr lastSun 2:00 1:00 D -Rule Halifax 1962 1973 - Apr lastSun 2:00 1:00 D -Rule Halifax 1962 1973 - Oct lastSun 2:00 0 S +Rule Halifax 1916 only - Apr 1 0:00 1:00 D +Rule Halifax 1916 only - Oct 1 0:00 0 S +Rule Halifax 1920 only - May 9 0:00 1:00 D +Rule Halifax 1920 only - Aug 29 0:00 0 S +Rule Halifax 1921 only - May 6 0:00 1:00 D +Rule Halifax 1921 1922 - Sep 5 0:00 0 S +Rule Halifax 1922 only - Apr 30 0:00 1:00 D +Rule Halifax 1923 1925 - May Sun>=1 0:00 1:00 D +Rule Halifax 1923 only - Sep 4 0:00 0 S +Rule Halifax 1924 only - Sep 15 0:00 0 S +Rule Halifax 1925 only - Sep 28 0:00 0 S +Rule Halifax 1926 only - May 16 0:00 1:00 D +Rule Halifax 1926 only - Sep 13 0:00 0 S +Rule Halifax 1927 only - May 1 0:00 1:00 D +Rule Halifax 1927 only - Sep 26 0:00 0 S +Rule Halifax 1928 1931 - May Sun>=8 0:00 1:00 D +Rule Halifax 1928 only - Sep 9 0:00 0 S +Rule Halifax 1929 only - Sep 3 0:00 0 S +Rule Halifax 1930 only - Sep 15 0:00 0 S +Rule Halifax 1931 1932 - Sep Mon>=24 0:00 0 S +Rule Halifax 1932 only - May 1 0:00 1:00 D +Rule Halifax 1933 only - Apr 30 0:00 1:00 D +Rule Halifax 1933 only - Oct 2 0:00 0 S +Rule Halifax 1934 only - May 20 0:00 1:00 D +Rule Halifax 1934 only - Sep 16 0:00 0 S +Rule Halifax 1935 only - Jun 2 0:00 1:00 D +Rule Halifax 1935 only - Sep 30 0:00 0 S +Rule Halifax 1936 only - Jun 1 0:00 1:00 D +Rule Halifax 1936 only - Sep 14 0:00 0 S +Rule Halifax 1937 1938 - May Sun>=1 0:00 1:00 D +Rule Halifax 1937 1941 - Sep Mon>=24 0:00 0 S +Rule Halifax 1939 only - May 28 0:00 1:00 D +Rule Halifax 1940 1941 - May Sun>=1 0:00 1:00 D +Rule Halifax 1946 1949 - Apr lastSun 2:00 1:00 D +Rule Halifax 1946 1949 - Sep lastSun 2:00 0 S +Rule Halifax 1951 1954 - Apr lastSun 2:00 1:00 D +Rule Halifax 1951 1954 - Sep lastSun 2:00 0 S +Rule Halifax 1956 1959 - Apr lastSun 2:00 1:00 D +Rule Halifax 1956 1959 - Sep lastSun 2:00 0 S +Rule Halifax 1962 1973 - Apr lastSun 2:00 1:00 D +Rule Halifax 1962 1973 - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Halifax -4:14:24 - LMT 1902 Jun 15 -4:00 Halifax A%sT 1918 @@ -1000,6 +1053,43 @@ Zone America/Glace_Bay -3:59:48 - LMT 19 -4:00 Halifax A%sT 1974 -4:00 Canada A%sT +# New Brunswick + +# From Paul Eggert (2006-01-20): +# New Brunswick's Time Definition Act +# <http://www.gnb.ca/0062/PDF-acts/t-06.pdf> says they change at 00:01, and +# <http://www.canlii.org/nb/laws/sta/t-6/20030127/whole.html> makes it +# clear that this has been the case since at least 1993. +# For now, assume it started in 1993. The Office of the Premier announced +# <http://www.gnb.ca/cnb/news/pre/2005e1737pr.htm> (2005-12-23) +# that they will bring forward proposed amendments to harmonize with the US; +# for now assume that this will happen, but they'll still switch at 00:01. + +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Moncton 1933 1935 - Jun Sun>=8 1:00 1:00 D +Rule Moncton 1933 1935 - Sep Sun>=8 1:00 0 S +Rule Moncton 1936 1938 - Jun Sun>=1 1:00 1:00 D +Rule Moncton 1936 1938 - Sep Sun>=1 1:00 0 S +Rule Moncton 1939 only - May 27 1:00 1:00 D +Rule Moncton 1939 1941 - Sep Sat>=21 1:00 0 S +Rule Moncton 1940 only - May 19 1:00 1:00 D +Rule Moncton 1941 only - May 4 1:00 1:00 D +Rule Moncton 1946 1972 - Apr lastSun 2:00 1:00 D +Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S +Rule Moncton 1956 1972 - Oct lastSun 2:00 0 S +Rule Moncton 1993 2006 - Apr Sun>=1 0:01 1:00 D +Rule Moncton 1993 2006 - Oct lastSun 0:01 0 S +Rule Moncton 2007 max - Mar Sun>=8 0:01 1:00 D +Rule Moncton 2007 max - Nov Sun>=1 0:01 0 S +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 + -5:00 - EST 1902 Jun 15 + -4:00 Canada A%sT 1933 + -4:00 Moncton A%sT 1942 + -4:00 Canada A%sT 1946 + -4:00 Moncton A%sT 1973 + -4:00 Canada A%sT 1993 + -4:00 Moncton A%sT # Ontario, Quebec =================================================================== RCS file: RCS/zone.tab,v retrieving revision 2005.12 retrieving revision 2005.12.0.1 diff -pu -r2005.12 -r2005.12.0.1 --- zone.tab 2005/08/22 16:05:26 2005.12 +++ zone.tab 2006/01/20 22:34:20 2005.12.0.1 @@ -100,8 +100,9 @@ BW -2545+02555 Africa/Gaborone BY +5354+02734 Europe/Minsk BZ +1730-08812 America/Belize CA +4734-05243 America/St_Johns Newfoundland Island -CA +4439-06336 America/Halifax Atlantic Time - Nova Scotia (most places), NB, W Labrador, E Quebec & PEI +CA +4439-06336 America/Halifax Atlantic Time - Nova Scotia (most places), W Labrador, E Quebec & PEI CA +4612-05957 America/Glace_Bay Atlantic Time - Nova Scotia - places that did not observe DST 1966-1971 +CA +4606-06447 America/Moncton Atlantic Time - New Brunswick CA +5320-06025 America/Goose_Bay Atlantic Time - E Labrador CA +4531-07334 America/Montreal Eastern Time - Quebec - most locations CA +4339-07923 America/Toronto Eastern Time - Ontario - most locations @@ -370,12 +371,14 @@ US +404251-0740023 America/New_York East US +421953-0830245 America/Detroit Eastern Time - Michigan - most locations US +381515-0854534 America/Kentucky/Louisville Eastern Time - Kentucky - Louisville area US +364947-0845057 America/Kentucky/Monticello Eastern Time - Kentucky - Wayne County -US +394606-0860929 America/Indiana/Indianapolis Eastern Standard Time - Indiana - most locations -US +382232-0862041 America/Indiana/Marengo Eastern Standard Time - Indiana - Crawford County -US +411745-0863730 America/Indiana/Knox Eastern Standard Time - Indiana - Starke County -US +384452-0850402 America/Indiana/Vevay Eastern Standard Time - Indiana - Switzerland County +US +394606-0860929 America/Indiana/Indianapolis Eastern Time - Indiana - most locations +US +382232-0862041 America/Indiana/Marengo Eastern Time - Indiana - Crawford County +US +411745-0863730 America/Indiana/Knox Eastern Time - Indiana - Starke County +US +384452-0850402 America/Indiana/Vevay Eastern Time - Indiana - Switzerland County US +415100-0873900 America/Chicago Central Time -US +450628-0873651 America/Menominee Central Time - Michigan - Wisconsin border +US +384038-0873143 America/Indiana/Vincennes Central Time - Indiana - Daviess, Dubois, Knox, Martin, Perry & Pulaski +US +382931-0871643 America/Indiana/Petersburg Central Time - Indiana - Pike County +US +450628-0873651 America/Menominee Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties US +470659-1011757 America/North_Dakota/Center Central Time - North Dakota - Oliver County US +394421-1045903 America/Denver Mountain Time US +433649-1161209 America/Boise Mountain Time - south Idaho & east Oregon =================================================================== RCS file: RCS/tz-link.htm,v retrieving revision 2005.16 retrieving revision 2005.16.0.1 diff -pu -r2005.16 -r2005.16.0.1 --- tz-link.htm 2005/11/29 19:30:51 2005.16 +++ tz-link.htm 2006/01/20 22:34:20 2005.16.0.1 @@ -9,7 +9,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"' /> <meta name="DC.Creator" content="Eggert, Paul" /> <meta name="DC.Contributor" content="Olson, Arthur David" /> -<meta name="DC.Date" content="2005-11-17" /> +<meta name="DC.Date" content="2006-01-20" /> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time" /> <meta name="DC.Identifier" content="http://www.twinsun.com/tz/tz-link.htm" /> @@ -31,7 +31,8 @@ that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to <a href="http://en.wikipedia.org/wiki/Time_zone">time zone</a> -boundaries, <a href="http://en.wikipedia.org/wiki/UTC"><abbr +boundaries, <a +href="http://en.wikipedia.org/wiki/Coordinated_Universal_Time"><abbr title="Coordinated Universal Time">UTC</abbr></a> offsets, and <a href="http://en.wikipedia.org/wiki/Daylight_saving">daylight-saving</a> rules. @@ -68,7 +69,8 @@ title="daylight saving time">DST</abbr>) <code>America/Detroit</code> represents most of Michigan, which uses eastern time but with different <abbr>DST</abbr> rules in 1975; and other entries represent smaller regions like Starke County, -Indiana, which switched from central to eastern time in 1991. +Indiana, which switched from central to eastern time in 1991 +and switched back in 2006. To use the database on an extended <a href="http://en.wikipedia.org/wiki/POSIX"><abbr title="Portable Operating System Interface">POSIX</abbr></a> @@ -141,7 +143,19 @@ title="Calendaring and Scheduling Workin covers time zone data; see its VTIMEZONE calendar component. The <a href="http://www.calconnect.org/">Calendaring and Scheduling -Consortium</a> is promoting further work in this area.</li> +Consortium</a> is promoting further work in this area. <a +href="ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-ical-basic-04.txt">iCalendar +Basic</a> is a draft simplified definition that omits VTIMEZONE due to +its complexity, but this removal is expected to appear as an +independent specification later.</li> +<li><a +href="ftp://ftp.rfc-editor.org/internet-drafts/draft-royer-timezone-registry-03.t…">Time +Zone Registry</a> proposes an <a href="http://www.iana.org/"><abbr +title="Internet Assigned Numbers Authority">IANA</abbr></a> time zone +registration process that would establish unique names for each +version of each <code>tz</code> zone, along with a polygonal +representation of the geographical area corresponding to the +zone.</li> <li>The <a href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a> list discusses <a @@ -196,6 +210,11 @@ is freely available under a <abbr>BSD</a Zone Library</a> compiles <code>tz</code> source into <a href="http://www.python.org/">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license.</li> +<li><a href="http://tzinfo.rubyforge.org/">TZInfo - Ruby Timezone Library</a> +compiles <code>tz</code> source into +<a href="http://www.ruby-lang.org/">Ruby</a>. +It is freely available under the <abbr +title="Massachusetts Institute of Technology">MIT</abbr> license.</li> </ul> <h2>Other <code>tz</code> binary file readers</h2> <ul> @@ -243,8 +262,12 @@ Microsoft Windows program.</li> <li><a href="http://www.astro.com/cgi/aq.cgi?lang=e">Atlas Query</a> is Astrodienst's Web version of Shanks's excellent time zone history atlases published in both <a -href="http://astrocom.com/products/software.php?software_id=ibmwboth">computer -and book form</a> by <a +href="http://astrocom.com/products/software.php?software_id=ibmwboth">computer</a> +and book form (<a +href="http://astrocom.com/products/book.php?book_id=b110x">one volume +for the USA</a>, and <a +href="http://astrocom.com/products/book.php?book_id=b112x">one for +other locations</a>) by <a href="http://astrocom.com/">Astro Communications Services</a>.</li> <li><a href="http://worldtime.com/">WORLDTIME: interactive atlas, time info, public holidays</a> @@ -424,7 +447,9 @@ href="http://www.cv.nrao.edu/~rfisher/Ep Times</a> explains more abstruse astronomical time scales like <abbr title="Terrestrial Dynamic Time">TDT</abbr>, <abbr title="Geocentric Coordinate Time">TCG</abbr>, and -<abbr title="Barycentric Dynamic Time">TDB</abbr>.</li> +<abbr title="Barycentric Dynamic Time">TDB</abbr>. +<a href="http://www.ucolick.org/~sla/leapsecs/timescales.html">Time +Scales</a> goes into more detail, particularly for historical variants.</li> <li>The <a href="http://www.iau.org/"><abbr title="International Astronomical Union">IAU</abbr></a>'s <a href="http://www.iau-sofa.rl.ac.uk/"><abbr @@ -444,6 +469,10 @@ describes Mars Coordinated Time (<abbr title="Mars Coordinated Time">MTC</abbr>) and the diverse local time scales used by each landed mission on Mars.</li> +<li><a href="http://www.leapsecond.com/">LeapSecond.com</a> is +dedicated not only to leap seconds but to precise time and frequency +in general. It covers the state of the art in amateur timekeeping, and +how the art has progressed over the past few decades.</li> <li><a href="http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html">Bulletins maintained by the @@ -467,8 +496,8 @@ title="Global Positioning System">GPS</a leap second: its history and possible future</a>, <a href="http://www.bipm.fr/metrologia/index.html">Metrologia</a> <strong>38</strong> (2001), 509–529. -<a href="http://www.ucolick.org/~sla/leapsecs/onlinebib.html">The -Future of Leap Seconds</a> catalogs information about this +<a href="http://www.ucolick.org/~sla/leapsecs/">The +Future of Leap Seconds</a> covers this contentious issue.</li> </ul> <h2>Time notation</h2> @@ -483,6 +512,10 @@ title="International Organization for St 8601:2004 -- Data elements and interchange formats -- Information interchange -- Representation of dates and times</a>.</li> <li> +<a href="http://www.w3.org/TR/xmlschema-2/#dateTime"><abbr>XML</abbr> +Schema: Datatypes - dateTime</a> specifies a format inspired by +<abbr>ISO</abbr> 8601 that is in common use in <abbr>XML</abbr> data.</li> +<li> Section 3.3 of <a href="ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt">Internet <abbr title="Request For Comments">RFC</abbr> 2822</a> @@ -495,6 +528,10 @@ headers.</li> profile for use in new Internet protocols.</li> <li> +<a href="http://www.hackcraft.net/web/datetime/">Date & Time +Formats on the Web</a> surveys web- and Internet-oriented date and time +formats.</li> +<li> <a href="http://www.exit109.com/~ghealton/y2k/yrexamples.html">The Best of Dates, the Worst of Dates</a> covers many problems encountered by software developers when handling dates and time stamps.</li>

4 9

Australia, ACT
by Brett Grace Jan. 25, 2006

Jan. 25, 2006

Daylight Savings haven't been adjusted for Canberra, ACT (Australia) to reflect the changes due to the Commonwealth Games There are very few personal problems that cannot be solved through a suitable application of high explosives.

1 0

RE: Docket No. 2005-22114
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2006

Jan. 24, 2006

> This cannot be exactly what was intended, because 2:00 a.m. EST corresponds to 1:00 a.m. CST, at which point clocks in the Central time zone will not > spring forward for another hour. Therefore, as written, the rule requires that a clock in the affected area must jump backwards from 02:00 EST to 01:00 > CST, and then an hour later jump ahead from 02:00 CST to 03:00 CDT. In other words, the currently-required clock transitions would look like this: > > 01:59:59 EST > ... and then, one second later,... > 01:00:00 CST > ... > ... > ... and then, one hour later,... > 01:59:59 CST > ... and then, one second later,... > 03:00:00 CDT > > We doubt whether you really intended that the citizens of Vincennes, Indiana should stay up in the middle of the night and change their clocks twice. The DOT-related problem is the over-zealous railroad engineer who parks his train for an hour when the clock falls back and then runs at high speed (increasing the chance of an accident) to make up time when the clock springs forward. I will not tempt fate by putting a smiley face here. In an unrelated matter, page 57 of the docket reads (in part) "We expect the economic impact of this proposed rule to be so minimal that a full Regulatory Evaluation...is unnecessary." Which raises the question: if changing clocks by an hour has such minimal economic impact, why are we playing the DST game in the first place? --ado

6 7

RE: Docket No. 2005-22114
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2006

Jan. 24, 2006

Recall that a message sent to the time zone mailing list isn't automatically forwarded unless it's from someone on the list (this is an anti-spam measure). I typically run through the raw feed each Monday and forward any relevant stuff from non-list senders. Since Paul sent the message to Judith S. Kaleta I've been checking on a daily basis; there's been nothing sent to the list yet. If we could just get Jon Stewart to "cover" the "story"... --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, January 23, 2006 7:00 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Docket No. 2005-22114 "Bill Bonnett" <news(a)abdicate.net> writes: > Has anyone bothered to contact DOT about this? Yes, I emailed Judith S. Kaleta, of the Office of the General Counsel of the DOT, and CC'ed to this list. No response yet.

1 0