- tz - lists.iana.org

RE: My confusion with Asia/Aqtau
by Olson, Arthur David (NIH/NCI) July 22, 2003

July 22, 2003

Dave Rolsky's interpretation of what the "asia" file *says* is happening is correct, as witness output from "zdump -v Asia/Aqtau | grep 1995": Asia/Aqtau Sat Mar 25 20:59:59 1995 UTC = Sun Mar 26 01:59:59 1995 AQTT isdst=0 Asia/Aqtau Sat Mar 25 21:00:00 1995 UTC = Sun Mar 26 03:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 17:59:59 1995 UTC = Sat Sep 23 23:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 18:00:00 1995 UTC = Sat Sep 23 23:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 21:59:59 1995 UTC = Sun Sep 24 02:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 22:00:00 1995 UTC = Sun Sep 24 02:00:00 1995 AQTT isdst=0 (Recall that for each time change zic produces a "before" and "after" line; six lines above means there were three changes in 1995). I don't know *really* happened in Asia/Aqtau in 1995; if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Friday, July 18, 2003 1:34 AM To: tz(a)lecserver.nci.nih.gov Subject: My confusion with Asia/Aqtau I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary). I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates. The observances for this zone include the following: 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT The RussiaAsia rules include the following rules which apply to those observances: Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - By my reading, this indicates the following transitions: * On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00. * On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00. Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code. OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

6 7

More strangenes in zdump: no LMT
by Dave Rolsky July 22, 2003

July 22, 2003

The data for Africa/Abidjan contains this: Zone Africa/Abidjan -0:16:08 - LMT 1912 0:00 - GMT But zdump gives me this: Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 GMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 gmtoff=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 gmtoff=0 The version of the time zone data installed on my system (GNU/Linux Debian unstable) may not match the version of the files I'm looking at (2003a) but I didn't think that the LMT name was something terribly recent. If look directly at the binary data for this zone on my system, I see that it does indeed contain the string "LMT". Any idea where this is getting munged? I'm trying to generate tests for my code based on the output of zdump, but I'm getting weird failures because of this problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

2 2

RE: Strange output from zdump for 2038
by Olson, Arthur David (NIH/NCI) July 21, 2003

July 21, 2003

The zdump manual page notes the output to be expected when using the -v option: -v For each zonename on the command line, print the time at the lowest possible time value, the time one day after the lowest possible time value, the times both one second before and exactly at each detected time discontinuity, the time at one day less than the highest possible time value, and the time at the highest possible time value, Each line ends with isdst=1 if the given time is Daylight Saving Time or isdst=0 otherwise. So the two 1901 lines and the two 2038 lines are to be expected. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Saturday, July 19, 2003 4:34 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Strange output from zdump for 2038 On Sat, 19 Jul 2003, Dave Rolsky wrote: > autarch@houseabsolute:~/DateTime/modules/DateTime-TimeZone$ zdump -v Asia/Aqtau | grep 2038 > > Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT isdst=0 gmtoff=14400 > Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT isdst=0 gmtoff=14400 > > Surely that's not right ;) I'd suggest that it's better to simply not > output anything rather than output bad data. Obviously this is related to > the 32-bit-ness of time_t, and is probably really a zic problem. The same problem occurs at the other end of integer: Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 GMT isdst=0 gmtoff=-968 Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 GMT isdst=0 gmtoff=-968 -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

3 2

RE: Strange output from zdump for 2038
by Olson, Arthur David (NIH/NCI) July 21, 2003

July 21, 2003

> The point is, however, that the gmtoff values are rubbish, the result of > using signed 32-bit values to model mathematical integers. The gmtoff values being output do seem to be the difference (in seconds) between UTC and local time. (It's true that the appearance of "GMT" is bogus but, as noted earlier, that seems to be a GNU challenge rather than a timeezone-package-as distributed problem.) --ado -----Original Message----- From: John Cowan [mailto:cowan@mercury.ccil.org] Sent: Monday, July 21, 2003 9:01 AM To: Olson, Arthur David (NIH/NCI) Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Strange output from zdump for 2038 Olson, Arthur David (NIH/NCI) scripsit: > So the two 1901 lines and the two 2038 lines are to be expected. The point is, however, that the gmtoff values are rubbish, the result of using signed 32-bit values to model mathematical integers. > > Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT > isdst=0 gmtoff=14400 > > Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT > isdst=0 gmtoff=14400 > Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 GMT > isdst=0 gmtoff=-968 > Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 GMT > isdst=0 gmtoff=-968 -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing: jcowan(a)reutershealth.com I'd use DTDs http://www.reutershealth.com If they had local trees -- http://www.ccil.org/~cowan I think I best switch to RELAX NG.

1 0

Re: FW: The zrd zone file reader
by Robert Elz July 21, 2003

July 21, 2003

When one sees code like ... long test = 0x01020304; if ((char *)&test == "\0x01\0x02\0x03\0x04") return s; it is a fair indication that the rest of it isn't going to be worth bothering about ... kre

1 0

Strange output from zdump for 2038
by Dave Rolsky July 19, 2003

July 19, 2003

autarch@houseabsolute:~/DateTime/modules/DateTime-TimeZone$ zdump -v Asia/Aqtau | grep 2038 Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT isdst=0 gmtoff=14400 Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT isdst=0 gmtoff=14400 Surely that's not right ;) I'd suggest that it's better to simply not output anything rather than output bad data. Obviously this is related to the 32-bit-ness of time_t, and is probably really a zic problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

1 1

The zrd zone file reader
by John Cowan July 18, 2003

July 18, 2003

I am submitting the following short program for possible inclusion in the next release of tzcode. Zrd (zone reader) is a program that dumps the contents of a binary zoneinfo file. It does not depend on the existing library in any way (except that it calls gmtime, but any gmtime will do), and provides a direct view into the contents of zoneinfo files. I have dedicated the program to the public domain. ===== cut here ==== /* zrd - a routine to dump the contents of a binary timezone file * Define ZONEINFO to be the directory where the timezone files are, * typically "/usr/share/zoneinfo/". * This program requires only stdio and "gmtime". * Public domain source by John Cowan <cowan(a)ccil.org> */ # define ZONEINFO "/usr/share/zoneinfo/" # include <stdio.h> # include <time.h> /* A handy routine that converts from network order * (big-endian) 32-bit values to local order. * It tests what local order is, and is not the most * efficient conceivable routine, but works OK * for this application. */ long my_ntohl(long s) { long r; char *ps; char *pr; long test = 0x01020304; if ((char *)&test == "\0x01\0x02\0x03\0x04") return s; ps = (char *) &s; pr = (char *) &r; pr[0] = ps[3]; pr[1] = ps[2]; pr[2] = ps[1]; pr[3] = ps[0]; return r; } /* The header of a timezone file. * It is followed by: * tzh_timecnt 32-bit values representing time transitions; * tzh_timecnt 1-byte indexes into the time type table; * the time type table, containing tzh_typecnt "struct ttinfo" elements; * the leap-second table, containing tzh_leapcnt "struct ttleap" elements; * tzh.isstdcnt 1-byte flags indicating if transitions are * based on local standard time or local current ("wall") time * tz.isgmtcnt 1-byte flags indicating if transitions are * based on UTC or local time */ struct tzhead { char tzh_magic[4]; /* magic number */ char tzh_reserved[16]; /* reserved for future use */ long tzh_ttisgmtcnt; /* coded number of trans. time flags */ long tzh_ttisstdcnt; /* coded number of trans. time flags */ long tzh_leapcnt; /* coded number of leap seconds */ long tzh_timecnt; /* coded number of transition times */ long tzh_typecnt; /* coded number of local time types */ long tzh_charcnt; /* coded number of abbr. chars */ }; /* A time type object */ struct ttinfo { long tt_gmtoff; /* offset of this time type from UTC */ char tt_isdst; /* whether this is a DST time type */ char tt_abbrind; /* index into the timezone name abbreviations */ }; /* A leap second object */ struct ttleap { long tt_time; /* The leap second */ long tt_seconds; /* New value of TAI - UTC - 10 */ }; char tzfilename[1024]; /* Filename of the timezone file */ FILE *tz; /* File stream for reading the file */ struct tzhead t; /* The file's header */ char tzdata[4096]; /* The rest of the file */ long tzsize; /* Size of tzdata in use */ /* Pointers to different parts of tzdata */ long *timep; char *timetypep; char *xtypep; struct ttinfo *typep; char *charp; struct ttleap *leapp; char *stdp; char *gmtp; main(argc, argv) int argc; char *argv[]; { int i; long gmtoff; int gmtsign; long clock; struct tm *d; char magic[5]; /* Validate command line and load header */ if (argc != 2) { fprintf(stderr, "usage: %s continent/location\n", argv[0]); exit(1); } strcpy(tzfilename, ZONEINFO); strcat(tzfilename, argv[1]); tz = fopen(tzfilename, "rb"); if (!tz) { fprintf(stderr, "%s: %s unknown\n", argv[0], argv[1]); exit(1); } fread(&t, sizeof(t), 1, tz); /* Localize values in the header */ strncpy(magic, t.tzh_magic, 4); magic[4] = 0; t.tzh_ttisgmtcnt = my_ntohl(t.tzh_ttisgmtcnt); t.tzh_ttisstdcnt = my_ntohl(t.tzh_ttisstdcnt); t.tzh_leapcnt = my_ntohl(t.tzh_leapcnt); t.tzh_typecnt = my_ntohl(t.tzh_typecnt); t.tzh_timecnt = my_ntohl(t.tzh_timecnt); t.tzh_charcnt = my_ntohl(t.tzh_charcnt); /* Read the rest of the file */ tzsize = fread(&tzdata, 1, sizeof(tzdata), tz); fclose(tz); /* Set up pointers to various sections */ timep = (long *)tzdata; timetypep = (char *)(timep + t.tzh_timecnt); xtypep = timetypep + t.tzh_timecnt; charp = xtypep + 6 * t.tzh_typecnt; /* alignment problem */ leapp = (struct ttleap *)(charp + t.tzh_charcnt); stdp = (char *)(leapp + t.tzh_leapcnt); gmtp = stdp + t.tzh_ttisstdcnt; /* Check for invalid file size */ if (tzdata + tzsize != gmtp + t.tzh_ttisgmtcnt) fprintf(stderr, "Warning: file is %ld bytes, expected %ld\n", tzsize + sizeof(t), (gmtp + t.tzh_ttisgmtcnt) - tzdata); /* Print magic number */ if (magic[0]) printf("TZ magic number is \"%s\" (normally \"TZif\")\n", magic); /* Print transition time table */ printf("%ld transition times:\n", t.tzh_timecnt); for (i = 0; i < t.tzh_timecnt; i++) { clock = my_ntohl(timep[i]); /* printf("\tat %ld use type %d\n", clock, timetypep[i]); */ d = gmtime(&clock); printf("\tat %4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d UTC (%ld) use type %d\n", d->tm_year + 1900, d->tm_mon+1, d->tm_mday, d->tm_hour, d->tm_min, d->tm_sec, clock, timetypep[i]); } /* Print time types table */ printf("%ld local time types:\n", t.tzh_typecnt); for (i = 0; i < t.tzh_typecnt; i++) { typep = (struct ttinfo *)(xtypep + i * 6); gmtoff = my_ntohl(typep->tt_gmtoff); if (gmtoff < 0) { gmtsign = -1; gmtoff = -gmtoff; } else if (gmtoff > 0) gmtsign = 1; else gmtsign = 0; printf("\ttype %d offset %2.2ld:%2.2ld:%2.2ld %s name (%d) %s", i, gmtsign*(gmtoff/3600), (gmtoff%3600)/60, gmtoff%60, typep->tt_isdst ? "isdst " : "notdst", typep->tt_abbrind, charp + typep->tt_abbrind); if (i < t.tzh_ttisstdcnt) printf(" %s", stdp[i] ? "std" : "wall"); if (i < t.tzh_ttisgmtcnt) printf(" %s", gmtp[i] ? "gmt" : "local"); printf("\n"); } /* Print time zone abbreviations */ printf("%ld bytes of abbreviations: [", t.tzh_charcnt); for (i = 0; i < t.tzh_charcnt; i++) if (charp[i]) putchar(charp[i]); else if (i != t.tzh_charcnt - 1) putchar('|'); printf("]\n"); /* Print leap second table */ printf("%ld leap second entries:\n", t.tzh_leapcnt); for (i = 0; i < t.tzh_leapcnt; i++) { clock = my_ntohl(leapp[i].tt_time); d = gmtime(&clock); printf("\tat %4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d UTC (%ld), TAI - UTC = %ld seconds\n", d->tm_year + 1900, d->tm_mon+1, d->tm_mday, d->tm_hour, d->tm_min, d->tm_sec, clock, my_ntohl(leapp[i].tt_seconds) + 10); } /* Print counts of gmt/local and std/wall flags (contents * have already been printed) */ printf("%ld std/wall flags\n", t.tzh_ttisstdcnt); printf("%ld gmt/local flags\n", t.tzh_ttisgmtcnt); exit(0); } ===== cut here ===== -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that jcowan(a)reutershealth.com hardly nobody could get there and most of http://www.reutershealth.com the leaders would stay home and let him go http://www.ccil.org/~cowan to work and do things as he pleased. --Mencken, _Declaration of Independence_

1 0

My confusion with Asia/Aqtau
by Dave Rolsky July 18, 2003

July 18, 2003

I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary). I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates. The observances for this zone include the following: 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT The RussiaAsia rules include the following rules which apply to those observances: Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - By my reading, this indicates the following transitions: * On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00. * On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00. Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code. OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

1 0

FW: cute quote
by Olson, Arthur David (NIH/NCI) July 14, 2003

July 14, 2003

Steve Summit is not on the time zone mailing list; direct replies appropriately. -----Original Message----- From: Steve Summit [mailto:scs@eskimo.com] Sent: Thursday, July 10, 2003 8:00 PM To: tz(a)lecserver.nci.nih.gov Cc: scs(a)eskimo.com Subject: cute quote I came across this quote, and (call me a timezone nurd) the first thing I thought of was the tz database, so I thought I'd pass it along: Don't worry about the world coming to an end today. It's already tomorrow in Australia. --- Charles Schulz Have a nice day (or tomorrow, as the case may be)...

1 0

cute quote
by Steve Summit July 11, 2003

July 11, 2003

I came across this quote, and (call me a timezone nurd) the first thing I thought of was the tz database, so I thought I'd pass it along: Don't worry about the world coming to an end today. It's already tomorrow in Australia. --- Charles Schulz Have a nice day (or tomorrow, as the case may be)...

1 0

FW: Bulletin C number 26
by Olson, Arthur David (NIH/NCI) July 10, 2003

July 10, 2003

>From iers(a)hpopa.obspm.fr Tue Jul 1 14:06:13 2003 Return-Path: <iers(a)hpopa.obspm.fr> Received: from hpopa.obspm.fr (hpopa.obspm.fr [145.238.100.44]) by lecserver.nci.nih.gov (8.12.9/8.12.9) with ESMTP id h61I6DdE016973 for <tz(a)elsie.nci.nih.gov>; Tue, 1 Jul 2003 14:06:13 -0400 (EDT) Received: (from iers@localhost) by hpopa.obspm.fr (8.8.6 (PHNE_14041)/8.7.1) id QAA25236 for adresc1; Tue, 1 Jul 2003 16:49:50 +0200 (METDST) Date: Tue, 1 Jul 2003 16:49:50 +0200 (METDST) From: iers(a)hpopa.obspm.fr Message-Id: <200307011449.QAA25236(a)hpopa.obspm.fr> To: adresc1(a)hpopa.obspm.fr Subject: Bulletin C number 26 Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Status: RO INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : iers(a)obspm.fr Paris, 1 July 2003 Bulletin C 26 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of December 2003. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Earth Orientation Center of IERS

1 0

Bulletin C number 26
by iers＠hpopa.obspm.fr July 1, 2003

July 1, 2003

INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : iers(a)obspm.fr Paris, 1 July 2003 Bulletin C 26 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of December 2003. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Earth Orientation Center of IERS

1 0

Karbala time in southern Iraq
by Paul Eggert June 22, 2003

June 22, 2003

On April 22 at about 0700 GMT the BBC News World Service reported that Shias in several southern Iraqi cities have changed their clocks to be "Karbala time". According to the story these Iraqis are 1 hour behind Baghdad, presumably because they are ignoring daylight-saving time. I heard the report on a radio station in Los Angeles, but haven't been able to find a copy at the BBC web site news.bbc.co.uk. Possibly the story was tape-delayed. This reminds me of the article in the Economist in June 2000, which said that Kurds were ignoring DST in northern Iraq. Rives McDow's excellent contacts at the time disagreed with this claim. Quite possibly a similar situation is occurring in southern Iraq right now.

2 1

TIME DIFFERENCE'S IN THE UNITED STATES AND AMERICA
by Sbbooties＠aol.com June 8, 2003

June 8, 2003

COULD YOU PLEASE SEND ME INFORMATION ON THE DIFFERENT TIME ZONES IN THE UNITED STATES AND ACROSS AMERICA

1 0

Timezone Database, still available?
by loren kaplan May 27, 2003

May 27, 2003

Hello, I've been searching the web for the latest and greatest version of the timezone database. Is it still available? I am unable to connect to the server so often referenced. Thanks and best regards, Loren Loren Kaplan UPS Supply Chain Solutions email: loren.kaplan(a)ups-scs.com phone: (415) 538-0520

1 0

Re: Canada's some little problems
by Paul Eggert May 27, 2003

May 27, 2003

> From: "Ciro Discepolo" <discepol(a)tin.it> > Date: Fri, 13 Jul 2001 14:50:36 +0200 > > I have noted some little problems respect DST in Canada analyzing > between Thomas Shanks data and the Time zone data I finally got around to decoding your attachment (sorry, I don't use Microsoft Word, so Word documents are a bit of a pain for me). Thanks very much for taking the time to correct the errors in the timezone tables; you must have gone to a lot of work! I have the following reaction to your comments: > Halifax does not use DST in the year 1932, while in the 1950 and > 1955 use a DST. Thanks for catching this error; I'll fix this in my next proposed patch. > From 1942 to 1944 Shanks says that ST JOHNS saved 1 hour (war time), > while in the timezone I've a normal DST from 1942 to 1944 without > stop. Here the timezone database was following Whitman rather than Shanks. However, Shanks seems more reliable about Canadian data than Whitman, so I'll change to Shanks here. > In the following table there are other date with difference from > Shanks, TIMEZONE and SHANKS contains the offset from GMT in DATE > TESTED. > > ZONE DATE TESTED TIMEZONE SHANKS > --------------------------------------------------------------------------- > GOOSE BAY 15-1-1943 3,3 2,3 > GOOSE BAY 15-1-1944 3,3 2,3 These discrepancies are for the same reason as St Johns, so changing St Johns will also remove these discrepancies. > GOOSE BAY 15-8-1917 2,3 3,3 > > NIPIGON 15-1-1941 5 4 > NIPIGON 15-1-1942 5 4 > > THUNDER BAY 15-1-1941 5 4 > THUNDER BAY 15-1-1942 5 4 > > RAINY RIV. 15-1-1941 6 5 > RAINY RIV. 15-1-1942 6 5 > > REGINA 15-8-1958 6 7 Thanks for catching these transcription errors; I'll fix them too. > MONTREAL 15-8-1917 5 4 But Montreal uses Canadian table #119, which says: 25 Mar 1917 2:00 4:00 24 Apr 1917 0:00 5:00 This means daylight saving time was not observed after April 24 of that year, so it seems to me that the SHANKS column should be "5". Perhaps the discrepancy is because you are using a different edition of Shanks? I am using the Revised 5th edition of Shanks's International Atlas <http://astrocom.com/books/full/b112x.php>. > WINNIPEG 15-1-1942 6 5 But Winnipeg uses Canadian table #171, which says: 26 Sep 1937 2:00 6:00 9 Feb 1942 2:00 5:00 so Shanks is saying that daylight saving time was not observed until February 9 of that year, so the SHANKS column should say "6". > EDMONTON 15/08/1918 6 7 But Edmonton uses Canadian table #179, which defers to table #5 for 1918, and table #5 says: 14 Apr 1918 2:00 6:00 31 Oct 1918 2:00 7:00 so the SHANKS column should say "6". > DAWSON FROM 1947 TO 1972 8 9 The timezone table says that Dawson was at 9 from 1947 to 1965; this agrees with Shanks, who uses Canadian time table #253. But that "1947 TO 1972" suggests to me that you've confused Dawson with Dawson Creek. Dawson Creek uses Canadian time table #251 and was at 8 (7 during summer) from 1947 to 1972. Thanks again for checking the database; your fixes should appear in the next version.

1 0

[(slightly) O/T] zic & leap seconds on Solaris 9
by Mariano Absatz May 12, 2003

May 12, 2003

Hi, I usually don't compile and install tzcode, and simply use the latest tzdata and compile the zones I need with the zic that my OS has... This has worked for linux and Solaris... or at least as far as I remember... now I wanted to use the "right" zones on a Solaris 9 machine and found that the zic that comes with Solaris doesn't support the "-L" option... So I downloaded & compiled tzcode (only adjusted the "cc = cc" line for using gcc). Everything went fine, I didn't install the software (it is in my home directory), but I ran: zic -d /usr/share/lib/zoneinfo/right -L leapseconds northamerica and it generated a new set of zone files in that directory. However, setting TZ to right/America/Mexico_City works exactly the same as if it were America/Mexico_City (i.e. I have _no_ 22 seconds difference). My (uninformed) guess is that maybe the old libraries cannot understand leap seconds although they are compiled in the zone files... I have a couple of questions: Am I completely off-base? :-) How could I replace the old version of the zoneinfo database, tools and libraries with a newer one? Browsing the Makefile, I see that the distribution of files is quite different from the one that appears to be standard in Solaris. Does anyone know of a ready-made Solaris 9 package I can use? I don't even know how to "uninstall" the default libraries or which files are involved... they don't appear to have the same names... This is a production machine and I wouldn't like to break it just to set the clock right :-) Any Solaris+Olson expertise would be greatly appreciated. TIA. -- Mariano Absatz - El Baby mailto:baby@baby.com.ar http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/'> Powered by Pegasus Mail /|__) http://www.pmail.com ) )\

2 1

IERS Message No. 44: Journees 2003 - First Circular.
by central_bureau＠iers.org April 30, 2003

April 30, 2003

************************************************************************ IERS Message No. 44 April 30, 2003 ************************************************************************ Dear Colleagues, Please find attached the first circular and the registration form for Journees 2003 "Astrometry, Geodynamics and Solar System Dynamics: from milliarcseconds to microarcseconds" to be held in the Institute of Applied Astronomy, St.Petersburg, Russia on Sep 22-25, 2003. The file is in Word format. If you have any problem with reading this file, please contact LOC for assistance. You can also find the first announcement and registration form at the IAA web-site http://www.ipa.nw.ru/conference/2003. Best regards, LOC of Journees 2003 ************************************************************************ 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. 43: Informations on the IERS Retreat 2003
by central_bureau＠iers.org April 28, 2003

April 28, 2003

************************************************************************ IERS Message No. 43 April 28, 2003 ************************************************************************ Dear Colleagues, An IERS Retreat has been organized in Paris on March 31 / April 1, 2003. The Retreat was convened to determine the future direction of the International Earth Rotation and Reference Systems Service (IERS) focusing on the improvement of the consistency and accuracy of its products. The minutes of the IERS Retreat 2003 are now online at http://www.iers.org/iers/meetings/IERS-Retreat-2003/ and can be downloaded as PDF file. The minutes include 4 annexes that are available as PDF files, too. With best regards Bernd Richter Director, IERS Central Bureau ************************************************************************ 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: 1960 Texas daylight saving time?
by Olson, Arthur David (NIH/NCI) April 26, 2003

April 26, 2003

Lisa Borel is not on the time zone mailing list; direct replies appropriately. The time zone database indicates that Houston, Texas (along with the bulk of the Central time zone) DID observe DST in 1960. --ado -----Original Message----- From: Lisa Borel [mailto:lisa.borel@earthlink.net] Sent: Thursday, April 24, 2003 8:27 AM To: tz(a)lecserver.nci.nih.gov Subject: 1960 Texas daylight saving time? Hi, Can anyone tell me whether Daylight saving time was observed in Houston, Texas in 1960? (please reply directly, as I am not a list member) Thanks, Lisa

2 1

1960 Texas daylight saving time?
by Lisa Borel April 24, 2003

April 24, 2003

Hi, Can anyone tell me whether Daylight saving time was observed in Houston, Texas in 1960? (please reply directly, as I am not a list member) Thanks, Lisa

1 0

TZCODE
by David Hoerl April 11, 2003

April 11, 2003

Hi - where is the latest TZCODE archived? I cannot ftp into elsie (well, I can get in, but I cannot see any files in /pub). David Hoerl, Director of Hardware Raritan Computers Inc

1 0

Can't read tz Database
by Wade Selvig April 10, 2003

April 10, 2003

I have tried to access the tz database via annymous hockup using Cute FTP, but I am unable to connect. Specifically, I get a "cannot resolve host name" error. What am I doing wrong? Please reply Wade Selvig Shaunavon, SK, Canada.

1 0

Washington Post DST coverage
by Olson, Arthur David (NIH/NCI) April 3, 2003

April 3, 2003

The 2003-04-02 Washington Post's "KidsPost" page (C15) features the story "Well, It's About Time: With Daylight Saving, You Gain an Hour of Fun in the Sun." Franklin's place, the reason for non-year-round DST, and the reason it's "Daylight Saving" rather than "Daylight Savings" are all covered. A pointer to www.time.gov is provided. --ado

1 0

RE: list headers, and filtering rules
by Dave Stewart March 26, 2003

March 26, 2003

I have a lot of "Rules" which all work fine, except for the TZ one, as I too was searching on Recipient info, which doesn't always work. >From the info in replies I have kindly been sent, and after further checking, it looks like the following criteria are the only ones that work all the time : Message Header contains "X-Mailing-List: <tz(a)elsie.nci.nih.gov>" OR Message Header contains "X-Loop: tz(a)elsie.nci.nih.gov" Thanks to all those who helped. Best Rgds, Dave Stewart Database Information Manager IT Systems Teletext Ltd. t: +44 (0) 20 8323 5707 f: +44 (0) 870 191 2159 e: Dave(a)teletext.co.uk -----Original Message----- From: Christoph Bugel [mailto:chris@tti-telecom.com <mailto:chris@tti-telecom.com> ] Sent: 24 March 2003 15:50 To: Hal Mueller Cc: Dave Stewart; tz(a)lecserver.nci.nih.gov Subject: Re: list headers, and filtering rules > You can filter the TZ list quite nicely by using the "Resent-From" > header or the presence of tz(a)lecserver.nci.nih.gov as a recipient. No > reason to pollute the subject line. Indeed. Or otherwise look for the X-Mailing-List header: X-Mailing-List: <tz(a)elsie.nci.nih.gov> See also http://www.tux.org/lkml/#s3-18 <http://www.tux.org/lkml/#s3-18> IMPORTANT NOTICE This communication contains information, which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender. The opinions expressed within this communication are not necessarily those expressed by Teletext Ltd. Teletext Ltd. Building 10 Chiswick Park 566 Chiswick High Road London W4 5TS Registered in England number 2694814 _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp

1 0