October 1993 - tz - lists.iana.org

proposal for time zone names
by eggert＠twinsun.com 20 Oct '93

20 Oct '93

I thought a bit about the problem of the explosion of time zone names, since we're looking at time zone rules for everywhere from Afghanistan to Zimbabwe. What do people think about time zone names of the from MAJOR_REGION/COUNTRY/CITY, e.g.: Africa/Zimbabwe/Harare Asia/Afghanistan/Kabul Europe/Albania/Tirana North_America/US/Los_Angeles Pacific/Fiji/Suva The ``major regions'' would be continents (Africa, North_ and South_ America, Antarctica, Australia, Asia, Europe) and oceans (Antarctic, Artic, Atlantic, Indian, Pacific). The ``minor regions'' would typically be countries. Only present-day English names for regions and cities would be used. The advantage of going to the detail of CITY is that we can use local mean time for times before standard time was introduced (e.g. before 1914 Jan 1 in Albania); this increases the accuracy of the database. Of course we should maintain links to traditional names like `Japan' and `US/Eastern' for backwards compatibility. Since I last wrote, I've coded up two sample countries. Asia/Afghanistan/Kabul needed just two lines of rules; Shanks says they've changed the rules only once since they adopted standard time in 1890. Europe/Albania/Tirana is a much more complicated 35-liner. Not only did it suffer the time zone vagaries of World War II, but also its dictatorship fiddled with the clocks seemingly at random between 1974 and 1984 before finally switching to the Polish rules. It looks like this will take some time.

1 0

problems with zoneinfo package passing VSX4 [forwarded with permission from grant@osf.org]
by ado 20 Oct '93

20 Oct '93

> From grant(a)osf.org Tue Oct 19 17:47:42 1993 > Return-Path: <grant(a)osf.org> > ... > Message-Id: <9310192147.AA24813(a)postman.osf.org> > To: ado(a)elsie.nci.nih.gov > Cc: grant(a)osf.org > Subject: problems with zoneinfo package passing VSX4 > Date: Tue, 19 Oct 1993 21:47:37 +0000 > From: Grant Sullivan <grant(a)osf.org> > ... > > I am a contract software engineer currently working for the Open Software > Foundation, Cambridge, MA. I last sent mail to you in August of this year > regarding my project to upgrade the next OSF/1 release to include the > zoneinfo package. > > I ended up using a sort of cut & paste approach to the project, using > the BSD 4.4 version of ctime.c, based on your earlier work, as my code > base for the libc changes, and "zic" additions. I compared those sources > with your June '93 kit, and merged in what appeared to be fixes. I also > included your entire June '93 zoneinfo source files. I had to make a few > other changes here and there to integrate everything into OSF/1. > > As a final functional check of libc, I was asked to run the VSX4 test > suite, before I would be allowed to formally submit the entire package > into the OSF/1 source pool. > > The VSX4 test suite found some problems with ctime(), localtime(), mktime(), > strftime() and tzset(). Most of these problems turned out to have a single > cause. For example, correcting the failure in ctime() fixed the problems > with localtime(), strftime(), tzset(), and some of the mktime() problems. > I thought you might be interested in knowing what changes I had to make to > pass VSX4. I am also stuck with one problem in mktime(), which you should > be aware of, and for which I am having trouble developing a solution. > > The VSX4 failure in ctime() involved a test case where TZ was set to > TZ=(255 A's)0(255 B's) > The number "255" corresponds to the POSIX.1 value for TZNAME_MAX. > The VSX4 ANSI.os/time/ctime/T.ctime test Assertion 11 failed when the > test checked the contents of tzname[] to see if it contained long A and > B strings. ctime() failed because tzset() return an error when it > found that the value of stdlen+1+dstlen+1 was greater than sizeof sp->chars. > The sizeof sp->chars was TZ_MAX_CHARS, set to "50" in tzfile.h. I reset > TZ_MAX_CHARS to 2*(TZNAME_MAX+1), in order to fix the VSX4 failure. > Additionally in tzparse(), I changed the size checks for "stdlen" and > "dstlen" to include upper limit checks against TZNAME_MAX, as follows: > . > . > } else { > name = getzname(name); > stdlen = name - stdname; > if ( stdlen < _POSIX_TZNAME_MAX || stdlen > TZNAME_MAX ) > return -1; > . > . > dstlen = name - dstname; /* length of DST zone name */ > if ( dstlen < _POSIX_TZNAME_MAX_POSIX_TZNAME_MAX || dstlen > TZNAME_MAX ) > return -1; > . > . > I also replaced "3" with _POSIX_TZNAME_MAX aboce. The additional limit > checks also make sure that the sum of the "std" and "dst" fields will > not exceed 2*(TZNAME_MAX+1) even if TZ_MAX_CHARS should be set to > something smaller. > > The changes to tzfile.h and tzparse() resulted in eliminating the VSX4 > failures of ctime(), localtime(), strftime(), tzset(), and some of the > mktime() failures. > > I have some temporary fixes for the mktime() failures, but I have not > been able to successfully fix the VSX4 failure of > ANSI.os/time/mktime/T.mktime assertion 10. Attempts I've made to fix > it have tended to cause other mktime() assertions to fail, and vice > versa. I suspect a flaw in the loop logic, or loop termination logic > in time2(), but it could also be a flaw in time1() or in localsub(). > > The VSX4 test of mktime fails when: > TZ=GMT0BST-2,J81,J300 > and mktime() is called with the following tm structure: > expected.tm_sec = 21; > expected.tm_min = 0; > expected.tm_hour = 2; > expected.tm_mday = 27; > expected.tm_mon = 9; > expected.tm_year = 88; > expected.tm_wday = -1; > expected.tm_yday = -1; > expected.tm_isdst = 1; > VSX4 is expecting mktime() to return a value in the range 593913621 - > 593913631 (allowing for the possibility that mktime() may include up to > 10 additional leap seconds. mktime() returned -1, instead. > > I believe the expected value is correct. VSX4 validates the mktime() > returned value by calling localtime() with the expected number and > comparing the expected and localtime()-generated tm structures. > > I believe that VSX4 is expecting mktime() to behave in accordance to > XPG4 with regards to how tm_isdst = 1 is handled on input to mktime(). > XPG4, "System Interfaces and Headers", page 275, says: > A positive or zero value for tm_isdst causes the mktime() > function to presume initially that Daylight Savings Time, > respectively, is or is not in effect for the specified time. > ... > mktime() seems to be having trouble when tm_isdst = 1, but the time/day > the tm data specified is just past the end of the daylight savings time > period. In the case above, the time is 21 seconds past the transition > back to standard time. > > I have tried things like resetting tm_isdst = 0 and recalculating, but > that works for some cases exercised by VSX4, but not for this > particular case. > > Have you heard of this VSX4 case? > > One area that is suspect is the extended loop in time2() which is based > on the "bits" counter. The comments above the "normalize" function > appear to pertain to this loop in time2(): > > /* > ** Adapted from code provided by Robert Elz, who writes: > ** The "best" way to do mktime I think is based on an idea of Bob > ** Kridle's (so its said...) from a long time ago. (mtxinu!kridle now). > ** It does a binary search of the time_t space. Since time_t's are > ** just 32 bits, its a max of 32 iterations (even at 64 bits it > ** would still be very reasonable). > */ > > I've added debugging statements to time2() to better understand what > the "bits" logic is about, and found that "bits" counter would often > get down to as low as "5" before jumping down to the next "for" loop. > For the case tested by VSX4, timecnt = 136, so if this were truly "a > binary search of the time_t space", I would not expect "bits" to drop > below 21. For the VXS4 test case, however, bits = 5 by the time the > loop has found a value of "t" that is in range (t=593920800). The > calculates to a linear search, rather than a binary search, since the > matching t = (sp->ats[37] + tt_gmtoff), and (37/2) is approx. (88-70) > is approx. (initial bits - final bits ) (31 - 5). I've tried setting > the tm_year = 92, however, and found the loop went through the same > number of cycles, so it I guess the search isn't really linear, but it > seems to me it could be faster. > > > I also noticed that your June '93 kit's version of timesub() contains > additional code vs. the BSD 4.4 version. I am wondering if this > additional code is a bug fix? > > Thanks for your assistance, > Grant W. Sullivan, > OSF/1 Commands & Libraries Group > Open Software Foundation > 11 Cambridge Center > Cambridge, MA 02142 > grant(a)osf.org > 617) 621-7249

1 0

Re: Shank's International Atlas [forwarded with permission from eggert@twinsun.com]
by ado 20 Oct '93

20 Oct '93

> From twinsun!twinsun.com!eggert(a)CS.UCLA.EDU Tue Oct 19 18:07:51 1993 > Return-Path: <twinsun!twinsun.com!eggert(a)CS.UCLA.EDU> > ... > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9310192204.AA24829(a)spot.twinsun.com> > Date: 19 Oct 1993 15:04:24 -0700 > To: ado(a)elsie.nci.nih.gov > In-Reply-To: <9310192039.AA26353(a)elsie.nci.nih.gov> (ado(a)elsie.nci.nih.gov) > Subject: Re: Shanks's International Atlas > ... > > That being so, we'd want to be on the lookout for rare timekeeping > changes and be sure to include them. > > Yes, definitely. (Ireland was an eye-opener for me.) > > 2. A pragmatic answer to how many zones to have for France is "as many as > are needed to describe the present day zones." As you noted, though, > doing even this at the country level yields lots of zones. > > If we were to do this, we'd need a convention to help decide which of the 153 > zone histories we'd present as `France'. I see two plausible options: pick > the present-day capital (i.e. Paris), or pick the most typical and widely-used > (for France, this would probably be Shanks's French Time Zone #1, which I > believe is the time zone history of the un-fought-over boondocks during the > two world wars). > > 3. As a last resort, simply reporting UCT for a zone when it's doing > something awkward is a possibility. > > If by `awkward' you mean LMT, I'd prefer using standard time instead, since > it's less of an error. E.g. if we use the district's present-day capital for > (2), then we could use the capital's LMT for times before standard time was > instituted. > > If we use present-day capitals, I think it'd be far more honest to give time > zone files names like `Paris' and `Berlin' instead of `France' and `Germany'. > This is reminiscent of the interface used in the HP 100LX palmtops -- they ask > you what city you're in, not what country you're in.

1 0

Re: Shank's International Atlas
by ado 20 Oct '93

20 Oct '93

Some initial feedback. 1. The notion in the README file is that > Historical local time information has been included here not because it > is particularly useful, but rather to: > > * give an idea of the variety of local time rules that have > existed in the past and thus an idea of the variety that may be > expected in the future; > > * provide a test of the generality of the local time rule description > system. That being so, we'd want to be on the lookout for rare timekeeping changes and be sure to include them. 2. A pragmatic answer to how many zones to have for France is "as many as are needed to describe the present day zones." As you noted, though, doing even this at the country level yields lots of zones. 3. As a last resort, simply reporting UCT for a zone when it's doing something awkward is a possibility. --ado

1 0

Shanks's International Atlas [forwarded with permission from eggert@twinsun.com]
by ado 20 Oct '93

20 Oct '93

> From twinsun!twinsun.com!eggert(a)CS.UCLA.EDU Tue Oct 19 15:08:13 1993 > Return-Path: <twinsun!twinsun.com!eggert(a)CS.UCLA.EDU> > ... > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9310191858.AA24533(a)spot.twinsun.com> > Date: 19 Oct 1993 11:58:24 -0700 > To: ado(a)elsie.nci.nih.gov > Subject: Shanks's International Atlas > ... > > In looking through Shanks's atlas I see a number of points that perhaps need > further thinking before I sit down and try to generate more tables. The main > point is that we need to decide what the limitations of the tz database should > be. I'd appreciate your advice on the following points, which are roughly in > decreasing order of seriousness. > > There are many, many tables. E.g. France has 153 tables; most of the variants > occurred during World War II, as the fortunes of war caused different > districts to switch between French and German time zone rules. Do we really > want a directory labeled `France' with 153 files in it, one per district? > Even coming up with the district names will be a chore, as Shanks merely gives > each table a number and, for each city, tells you which time table it uses. > > Even the number of countries would mean that the timezone database would be > very bushy at top level, with entries ranging from Afghanistan to Zimbabwe. > Perhaps some substructure is in order. At some point you mentioned using ISO > country codes? (But how many people know their country code?) > > The current code makes no provision for when a district changed from LMT to > standard time (e.g. 1914 Jan 1 in Albania). Strictly speaking, it's incorrect > to give times other than LMT before the switch. At least we should put in a > comment when LMT began, I suppose. But should there be some provision in the > code as well? I suppose it would be something like a suffix to the TZ value > which specifies the LMT offset when LMT is in effect, since you can't possibly > have a table for each LMT offset. > > I doubt whether the following points are worth worrying about in the code, > but perhaps there should be a commenting convention for documenting these > points. > > Some countries switched from the Gregorian to the Julian calendar in this > century; e.g. part of Bulgaria held out until 1920 Sept 17 (Gregorian). I > suppose this is too much for the TZ code to handle, but perhaps comments are > in order. > > The Soviet Union instituted a 5 day week in 1929, a 6 day week in 1932, and > reverted to a 7 day week in 1940. > > China changed from the Chinese calendar on 1912 Feb 12 (Gregorian); > Japan from the Japanese calendar on 1893 Jan 1 (Gregorian). > > There was a time before LMT, when people used apparent time, not mean time. > E.g. Paris switched from apparent time to LMT in 1816.

1 0

Re: Shank's International Atlas, with GB-Eire as a test case
by ado 15 Oct '93

15 Oct '93

Paul Eggert's changes are now incorporated in the files tzcode93f.tar.Z and tzdata93f.tar.Z in the ~ftp/pub directory of elsie.nci.nih.gov (128.231.16.1). Thanks to Paul Eggert for the information! --ado

1 0

Shank's International Atlas, with GB-Eire as a test case
by eggert＠twinsun.com 15 Oct '93

15 Oct '93

I just found the book Thomas G. Shanks The International Atlas (3rd ed) San Diego: ACS Publications, Inc. (1991) xx + 428 pp. ISBN 0-935127-16-X, $36, order phone: +1 800 888 9983 which lists detailed historical time zone data, plus latitude and longitude, for places all over the world. For example, for Germany it lists over 20 pages of data in fine print, of which one page contains seven different historical time zone regions and the complete history of all GMT offsets in each region since the 1890s (when Germany started using standard time). There's a separate atlas (which I don't have) for US time zone data. ACS Publications serves astrologers, who seem to be the folks who care most about historical time zone data. (You get a 20% discount on your second order if you tell them your sun sign!) To see if it was good stuff, I checked Shanks's book vs the tz1993d rules for Great Britain and Eire. In nearly every case where Shanks disagreed with tz1993d, it seems to me that Shanks is more likely to be correct. The discrepancies included the following: * transcription errors in 1916, 1923, and 1968, where the tz1993d data doesn't match Peter Ilieve's transcription of the UK Government paper "Summer Time: A Consultation Document". * Shanks says summer time began in 1924 in 13 April, which seems far more likely to be correct than Ilieve's 30 April, since 30 April 1924 was a Wednesday. * Shanks says Eire did not observe war time during World War II, which seems likely since Eire was neutral. He says that Eire stayed an hour ahead of GMT through the war, and then had its own summer time scheme until 1948 when it reverted to GB time. * Shanks says Eire was 25 minutes behind GMT until 1916, switched to 35 minutes ahead of GMT during summer 1916, and then switched the clocks twice (!) on the morning of 1 Oct 1916, first to 1 hour ahead of GMT, then (35 minutes later) to GMT. This is the only hard-to-believe part of Shanks's data, but it's just crazy enough to be true. That last bit exposed another zdump bug: if the clock changes more than once in the same 12-hour period it sometimes misses some of the changes. I doubt whether Shanks is infallible -- his data for Israel looks funny, and he doesn't agree with the stories I've heard about the Soviet Union in the 1930s -- but it does seem like a good source, at least for those parts of the world where horoscopes are popular. Here's a proposed patch. =================================================================== RCS file: RCS/zdump.c,v retrieving revision 7.7 retrieving revision 7.7.1.1 diff -c -r7.7 -r7.7.1.1 *** zdump.c 1993/09/06 01:21:19 7.7 --- zdump.c 1993/10/15 00:18:49 7.7.1.1 *************** *** 82,88 **** static char * abbr(); static long delta(); ! static void hunt(); static int longest; static char * progname; static void show(); --- 82,88 ---- static char * abbr(); static long delta(); ! static time_t hunt(); static int longest; static char * progname; static void show(); *************** *** 177,183 **** if (delta(&newtm, &tm) != (newt - t) || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), buf) != 0) { ! hunt(argv[i], t, newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); } --- 177,184 ---- if (delta(&newtm, &tm) != (newt - t) || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), buf) != 0) { ! newt = hunt(argv[i], t, newt); ! newtm = *localtime(&newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); } *************** *** 208,214 **** ; } ! static void hunt(name, lot, hit) char * name; time_t lot; --- 209,215 ---- ; } ! static time_t hunt(name, lot, hit) char * name; time_t lot; *************** *** 237,242 **** --- 238,244 ---- } show(name, lot, TRUE); show(name, hit, TRUE); + return hit; } /* =================================================================== RCS file: RCS/europe,v retrieving revision 7.5 retrieving revision 7.5.1.1 diff -c -r7.5 -r7.5.1.1 *** europe 1993/09/06 01:21:38 7.5 --- europe 1993/10/15 00:19:31 7.5.1.1 *************** *** 7,12 **** --- 7,16 ---- # ahead and edit the file (and please send any changes to # ado(a)ncifcrf.gov for general use in the future). + # A good source for time zone historical data outside the U.S. is + # Thomas G. Shanks, The International Atlas (3rd edition), + # San Diego: ACS Publications, Inc. (1991). + ############################################################################### # United Kingdom *************** *** 52,58 **** # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September ! # 1924 30 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # --- 56,62 ---- # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September ! # 1924 13 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # *************** *** 120,125 **** --- 124,139 ---- # # These dates agree with the ones from Whitaker's Almanac for 1960--87. . . + # From Paul Eggert (October 14, 1993) + # + # I changed the date `30 April 1924' to `13 April 1924' in the above table + # to fix what must be transcription error, since 30 April is not a Sunday, + # and Shanks gives 13 April which is a Sunday. + # + # The rules for Eire below are taken from Shanks, and reflect his claim that + # Eire changed the clock twice on 1 Oct 1916. I invented `IST' and `IDT' as + # abbreviations for Eire's standard and daylight time before 1 Oct 1916. + # From Arthur David Olson (January 19, 1989): # # A source at the British Information Office in New York avers that it's *************** *** 210,216 **** # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular ! Rule GB-Eire 1916 only - Mar 21 2:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 2:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 2:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 2:00s 0 GMT --- 224,230 ---- # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular ! Rule GB-Eire 1916 only - May 21 2:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 2:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 2:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 2:00s 0 GMT *************** *** 225,232 **** Rule GB-Eire 1922 only - Mar 26 2:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 2:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 2:00s 1:00 BST ! Rule GB-Eire 1923 only - Oct 16 2:00s 0 GMT ! Rule GB-Eire 1924 only - Apr 30 2:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 2:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 2:00s 1:00 BST --- 239,246 ---- Rule GB-Eire 1922 only - Mar 26 2:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 2:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 2:00s 1:00 BST ! Rule GB-Eire 1923 only - Sep 16 2:00s 0 GMT ! Rule GB-Eire 1924 only - Apr 13 2:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 2:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 2:00s 1:00 BST *************** *** 266,272 **** Rule GB-Eire 1960 only - Apr 10 2:00s 1:00 BST Rule GB-Eire 1961 1963 - Mar lastSun 2:00s 1:00 BST Rule GB-Eire 1964 1967 - Mar Sun>=19 2:00s 1:00 BST - Rule GB-Eire 1968 only - Feb 18 2:00s 1:00 BST Rule GB-Eire 1972 1980 - Mar Sun>=16 2:00s 1:00 BST # 1953 to 1980, ending rules Rule GB-Eire 1953 1960 - Oct Sun>=1 2:00s 0 GMT --- 280,285 ---- *************** *** 278,284 **** Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone GB-Eire 0:00 GB-Eire %s 1968 Oct 27 2:00s 1:00 - BST 1971 Oct 31 2:00s 0:00 GB-Eire %s --- 291,309 ---- Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone GB 0:00 - GMT 1916 May 21 2:00s ! 0:00 GB-Eire %s 1968 Feb 18 2:00s ! 1:00 - BST 1971 Oct 31 2:00s ! 0:00 GB-Eire %s ! Zone Eire -0:25 - IST 1916 May 21 2:00 ! -0:25 1:00 IDT 1916 Oct 1 2:00 ! 0:00 1:00 BST 1916 Oct 1 3:00 ! 0:00 GB-Eire %s 1940 Feb 25 2:00 ! 0:00 1:00 BST 1946 Oct 6 2:00 ! 0:00 - GMT 1947 Mar 16 2:00 ! 0:00 1:00 BST 1947 Nov 2 2:00 ! 0:00 - GMT 1948 Apr 18 2:00 ! 0:00 GB-Eire %s 1968 Feb 18 2:00s 1:00 - BST 1971 Oct 31 2:00s 0:00 GB-Eire %s

1 0

Timezone info on BSDI Date & Time gateway
by bostic＠vangogh.CS.Berkeley.EDU 06 Oct '93

06 Oct '93

>From sanders(a)BSDI.COM Tue Oct 5 19:42:36 1993 To: eng(a)BSDI.COM Subject: I knew this internet connection was good for something... Date: Tue, 05 Oct 1993 18:43:48 -0500 From: Tony Sanders <sanders(a)BSDI.COM> ------- Forwarded Message Received: from probitas.cs.utas.edu.au by austin.BSDI.COM (5.67/1.37) id AA09594; Tue, 5 Oct 93 18:21:17 -0500 Received: from brian.cs.utas.edu.au by probitas.cs.utas.edu.au (AIX 3.2/UCB 5.64/4.03) id AA41183; Wed, 6 Oct 1993 10:21:41 +1000 Message-Id: <9310060021.AA41183(a)probitas.cs.utas.edu.au> X-Sender: brian(a)probitas.cs.utas.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Oct 1993 10:21:10 +1000 To: sanders(a)www.bsdi.com From: Brian.Marriott(a)probitas.cs.utas.edu.au (Brian Marriott) Subject: Timezone info on BSDI Date & Time gateway Hi Tony I just had occasion to check the BSDI Date & Time gateway via www. Congratulations, it looks good - a great idea. You've got one minor thing wrong in your timezone info, though (through no fault of yours). The timezone for Tasmania, Australia shows currently as GMT+10, but it's actually at GMT+11. A recent bureaucratic decision means that Tasmania switches to daylight saving (GMT+11) on the first Sunday in October (at 0200, GMT+10), and switches back to Eastern Australian Standard Time (GMT+10) on the last Sunday in March (at 0200, GMT+11). You can't be expected to be aware of this, I know, because it was only recently announced here in Tasmania. Cheers, Brian Marriott (a non-animated Tasmanian Devil) - ------------------------------------------------------------- Brian Marriott AARNet: Brian.Marriott(a)cs.utas.edu.au Department of Computer Science University of Tasmania Phone: 002 202 929 Fax: 002 202 913 (Int'l +61 02 202 913) Postal address: GPO Box 252C, Hobart Tasmania 7001, Australia ------- End of Forwarded Message

1 0