- tz - lists.iana.org

proposal for time zone names
by eggert＠twinsun.com Oct. 20, 1993

Oct. 20, 1993

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 Oct. 20, 1993

Oct. 20, 1993

> 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 Oct. 20, 1993

Oct. 20, 1993

> 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 Oct. 20, 1993

Oct. 20, 1993

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 Oct. 20, 1993

Oct. 20, 1993

> 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 Oct. 15, 1993

Oct. 15, 1993

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 Oct. 15, 1993

Oct. 15, 1993

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 Oct. 6, 1993

Oct. 6, 1993

>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

tzcode93e.tar.Z and tzdata93e.tar.Z
by ado Sept. 6, 1993

Sept. 6, 1993

Updated versions of the time zone stuff are available by anonymous ftp from elsie.nci.nih.gov (128.231.16.1); you'll want the files tzcode93e.tar.Z and tzdata93e.tar.Z from the "pub" directory. There's updated data for Israel, England, and Kwajalein; there's also an update to "zdump" to cope with Kwajalein's 24-hour jump. Thanks to Paul Eggert and Peter Ilieve for the changes. --ado

1 0

latest entries for Israeli time zones
by eggert＠twinsun.com Sept. 5, 1993

Sept. 5, 1993

After I wrote a note in comp.risks about Solaris 2.2 time zone bugs, I got a message from Yitschak Goldberg <yits(a)eandm.co.il> that the latest Olson tables weren't right either. After asking around, Ephraim Silverberg kindly sent me his latest info; I enclose his note at the end of this message. So I propose the following patch to the `asia' file. ----- start of patch ----- =================================================================== RCS file: asia,v retrieving revision 7.4 retrieving revision 7.4.1.1 diff -c -r7.4 -r7.4.1.1 *** asia 1993/06/18 03:34:10 7.4 --- asia 1993/09/05 09:58:16 7.4.1.1 *************** *** 89,315 **** # year; as information, regarding exact times and dates during this period, # is not readily available at the present time, the rules commence starting # with the year 1989. - # - # From 1989 onwards the rules are as follows: - # - # 1. Daylight Savings Time commences midnight of the first Saturday night - # following the seven-day festival of Pesach (Passover). The transition - # is from midnight Israel Standard Time to 1 a.m. Israel Daylight Savings - # time. As the Pesach festival is dependent on the Lunar calendar (the - # first day is always on the 15th day of the month of Nisan), the rule - # changes every year on the Gregorian calendar. - # - # 2. Standard Time is reinstated on the Saturday night whereupon Jews - # following the Ashkenazi (European) rite begin to recite the Selichot - # (forgiveness) prayers prior to the Jewish Lunar New Year. The transition - # is from midnight Israel Daylight Savings time to 11 p.m. Israel Standard - # Time. The law (according to the Ashkenazi custom) concerning the - # commencement of the Selichot prayers is described in chapter 128, section - # 5 of the "Code of Jewish Law," by Rabbi Shlomo Ganzfried (translated by - # Hyman E. Goldin): - # - # Beginning with the Sunday [**] before Rosh Hashanah [***], - # we rise early for the service of Selichot (supplications for - # forgiveness). If Rosh Hashanah occurs on Monday or Tuesday, we - # begin saying the Selichot from the Sunday of the preceding week. - # - # This, too, varies from year to year on the Gregorian calendar and, thus, - # two explicit timezone rules are required for each Gregorian year. - # - # [**] actually Saturday night as the Jewish day commences at nightfall. - # [***] the Jewish Lunar New Year. ! # From Paul Eggert (June 16, 1993). Ed Reingold and I converted the above ! # rules into the following Emacs lisp code. It requires GNU Emacs 19.13 ! # or later. If you run the code, the Zion rules will be inserted into ! # your Emacs buffer. Reference: ``Calendrical Calculations'' by Nachum ! # Dershowitz and Edward M. Reingold, Software--Practice and Experience, ! # Volume 20, Number 9 (September, 1990), pages 899-928. # ! # (calendar-for-loop ! # year from 1989 to 2037 do ! # (let ((dst-starts ! # (calendar-gregorian-from-absolute ! # (calendar-dayname-on-or-before ! # 0 ! # (calendar-absolute-from-hebrew ! # (list 1 28 (+ year 3760)))))) ! # (dst-ends ! # (calendar-gregorian-from-absolute ! # (calendar-dayname-on-or-before ! # 0 ! # (- (calendar-absolute-from-hebrew (list 7 1 (+ year 3761))) 3))))) ! # (insert (format "Rule\tZion\t%d\tonly\t-\t%3s\t%2d\t0:00\t1:00\tD\n" ! # year ! # (substring ! # (calendar-month-name (extract-calendar-month dst-starts)) ! # 0 3) ! # (extract-calendar-day dst-starts))) ! # (insert (format "Rule\tZion\t%d\tonly\t-\t%3s\t%2d\t0:00\t0:00\tS\n" ! # year ! # (substring ! # (calendar-month-name (extract-calendar-month dst-ends)) ! # 0 3) ! # (extract-calendar-day dst-ends))))) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D ! Rule Zion 1989 only - Sep 24 0:00 0:00 S ! Rule Zion 1990 only - Apr 22 0:00 1:00 D ! Rule Zion 1990 only - Sep 16 0:00 0:00 S ! Rule Zion 1991 only - Apr 7 0:00 1:00 D Rule Zion 1991 only - Sep 1 0:00 0:00 S ! Rule Zion 1992 only - Apr 26 0:00 1:00 D ! Rule Zion 1992 only - Sep 20 0:00 0:00 S ! Rule Zion 1993 only - Apr 18 0:00 1:00 D ! Rule Zion 1993 only - Sep 12 0:00 0:00 S ! Rule Zion 1994 only - Apr 3 0:00 1:00 D ! Rule Zion 1994 only - Aug 28 0:00 0:00 S ! Rule Zion 1995 only - Apr 23 0:00 1:00 D ! Rule Zion 1995 only - Sep 17 0:00 0:00 S ! Rule Zion 1996 only - Apr 14 0:00 1:00 D ! Rule Zion 1996 only - Sep 8 0:00 0:00 S ! Rule Zion 1997 only - May 4 0:00 1:00 D ! Rule Zion 1997 only - Sep 28 0:00 0:00 S ! Rule Zion 1998 only - Apr 19 0:00 1:00 D ! Rule Zion 1998 only - Sep 13 0:00 0:00 S ! Rule Zion 1999 only - Apr 11 0:00 1:00 D ! Rule Zion 1999 only - Sep 5 0:00 0:00 S ! Rule Zion 2000 only - Apr 30 0:00 1:00 D ! Rule Zion 2000 only - Sep 24 0:00 0:00 S ! Rule Zion 2001 only - Apr 15 0:00 1:00 D ! Rule Zion 2001 only - Sep 9 0:00 0:00 S ! Rule Zion 2002 only - Apr 7 0:00 1:00 D ! Rule Zion 2002 only - Sep 1 0:00 0:00 S ! Rule Zion 2003 only - Apr 27 0:00 1:00 D ! Rule Zion 2003 only - Sep 21 0:00 0:00 S ! Rule Zion 2004 only - Apr 18 0:00 1:00 D ! Rule Zion 2004 only - Sep 12 0:00 0:00 S ! Rule Zion 2005 only - May 1 0:00 1:00 D ! Rule Zion 2005 only - Sep 25 0:00 0:00 S ! Rule Zion 2006 only - Apr 23 0:00 1:00 D ! Rule Zion 2006 only - Sep 17 0:00 0:00 S ! Rule Zion 2007 only - Apr 15 0:00 1:00 D ! Rule Zion 2007 only - Sep 9 0:00 0:00 S ! Rule Zion 2008 only - Apr 27 0:00 1:00 D ! Rule Zion 2008 only - Sep 21 0:00 0:00 S ! Rule Zion 2009 only - Apr 19 0:00 1:00 D ! Rule Zion 2009 only - Sep 13 0:00 0:00 S ! Rule Zion 2010 only - Apr 11 0:00 1:00 D ! Rule Zion 2010 only - Sep 5 0:00 0:00 S ! Rule Zion 2011 only - May 1 0:00 1:00 D ! Rule Zion 2011 only - Sep 25 0:00 0:00 S ! Rule Zion 2012 only - Apr 15 0:00 1:00 D ! Rule Zion 2012 only - Sep 9 0:00 0:00 S ! Rule Zion 2013 only - Apr 7 0:00 1:00 D ! Rule Zion 2013 only - Sep 1 0:00 0:00 S ! Rule Zion 2014 only - Apr 27 0:00 1:00 D ! Rule Zion 2014 only - Sep 21 0:00 0:00 S ! Rule Zion 2015 only - Apr 12 0:00 1:00 D ! Rule Zion 2015 only - Sep 6 0:00 0:00 S ! Rule Zion 2016 only - May 1 0:00 1:00 D ! Rule Zion 2016 only - Sep 25 0:00 0:00 S ! Rule Zion 2017 only - Apr 23 0:00 1:00 D ! Rule Zion 2017 only - Sep 17 0:00 0:00 S ! Rule Zion 2018 only - Apr 8 0:00 1:00 D ! Rule Zion 2018 only - Sep 2 0:00 0:00 S ! Rule Zion 2019 only - Apr 28 0:00 1:00 D ! Rule Zion 2019 only - Sep 22 0:00 0:00 S ! Rule Zion 2020 only - Apr 19 0:00 1:00 D ! Rule Zion 2020 only - Sep 13 0:00 0:00 S ! Rule Zion 2021 only - Apr 4 0:00 1:00 D ! Rule Zion 2021 only - Aug 29 0:00 0:00 S ! Rule Zion 2022 only - Apr 24 0:00 1:00 D ! Rule Zion 2022 only - Sep 18 0:00 0:00 S ! Rule Zion 2023 only - Apr 16 0:00 1:00 D ! Rule Zion 2023 only - Sep 10 0:00 0:00 S ! Rule Zion 2024 only - May 5 0:00 1:00 D ! Rule Zion 2024 only - Sep 29 0:00 0:00 S ! Rule Zion 2025 only - Apr 20 0:00 1:00 D ! Rule Zion 2025 only - Sep 14 0:00 0:00 S ! Rule Zion 2026 only - Apr 12 0:00 1:00 D ! Rule Zion 2026 only - Sep 6 0:00 0:00 S ! Rule Zion 2027 only - May 2 0:00 1:00 D ! Rule Zion 2027 only - Sep 26 0:00 0:00 S ! Rule Zion 2028 only - Apr 23 0:00 1:00 D ! Rule Zion 2028 only - Sep 17 0:00 0:00 S ! Rule Zion 2029 only - Apr 8 0:00 1:00 D ! Rule Zion 2029 only - Sep 2 0:00 0:00 S ! Rule Zion 2030 only - Apr 28 0:00 1:00 D ! Rule Zion 2030 only - Sep 22 0:00 0:00 S ! Rule Zion 2031 only - Apr 20 0:00 1:00 D ! Rule Zion 2031 only - Sep 14 0:00 0:00 S ! Rule Zion 2032 only - Apr 4 0:00 1:00 D ! Rule Zion 2032 only - Aug 29 0:00 0:00 S ! Rule Zion 2033 only - Apr 24 0:00 1:00 D ! Rule Zion 2033 only - Sep 18 0:00 0:00 S ! Rule Zion 2034 only - Apr 16 0:00 1:00 D ! Rule Zion 2034 only - Sep 10 0:00 0:00 S ! Rule Zion 2035 only - May 6 0:00 1:00 D ! Rule Zion 2035 only - Sep 30 0:00 0:00 S ! Rule Zion 2036 only - Apr 20 0:00 1:00 D ! Rule Zion 2036 only - Sep 14 0:00 0:00 S ! Rule Zion 2037 only - Apr 12 0:00 1:00 D ! Rule Zion 2037 only - Sep 6 0:00 0:00 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 2:00 Zion I%sT - - # The following is a chart of the day of the week and Gregorian date of - # the first day of Pesach and the first day of Rosh Hashanah for the years - # 1989 through 2009 inclusive. - # - # First Day of Passover - # --------------------- - # Gregorian Year Day of Week Month Day - # -------------- ----------- ----- --- - # 1989 Thursday April 20 - # 1990 Tuesday April 10 - # 1991 Saturday March 30 - # 1992 Saturday April 18 - # 1993 Tuesday April 6 - # 1994 Sunday March 27 - # 1995 Saturday April 15 - # 1996 Thursday April 4 - # 1997 Tuesday April 22 - # 1998 Saturday April 11 - # 1999 Thursday April 1 - # 2000 Thursday April 20 - # 2001 Sunday April 8 - # 2002 Thursday March 28 - # 2003 Thursday April 17 - # 2004 Tuesday April 6 - # 2005 Sunday April 24 - # 2006 Thursday April 13 - # 2007 Tuesday April 3 - # 2008 Sunday April 20 - # 2009 Thursday April 9 - # - # First Day of Rosh Hashanah - # -------------------------- - # Gregorian Year Day of Week Month Day - # -------------- ----------- ----- --- - # 1989 Saturday September 30 - # 1990 Thursday September 20 - # 1991 Monday September 9 - # 1992 Monday September 28 - # 1993 Thursday September 16 - # 1994 Tuesday September 6 - # 1995 Monday September 25 - # 1996 Saturday September 14 - # 1997 Thursday October 2 - # 1998 Monday September 21 - # 1999 Saturday September 11 - # 2000 Saturday September 30 - # 2001 Tuesday September 18 - # 2002 Saturday September 7 - # 2003 Saturday September 27 - # 2004 Thursday September 16 - # 2005 Tuesday October 4 - # 2006 Saturday September 23 - # 2007 Thursday September 13 - # 2008 Tuesday September 30 - # 2009 Saturday September 19 ############################################################################### --- 89,132 ---- # year; as information, regarding exact times and dates during this period, # is not readily available at the present time, the rules commence starting # with the year 1989. ! # From Ephraim Silverberg (September 5, 1993): # ! # According to the Office of the Secretary General of the Ministry of ! # Interior, there is NO set rule for Daylight-Savings/Standard time changes. ! # Each year they decide anew what havoc to wreak on the country. However, ! # there is a "supposed" set of rules which is subject to change depending ! # on the party the Minister of Interior, the size of the coalition ! # government, the phase of the moon and the direction of the wind. Hence, ! # changes may need to be made on a semi-annual basis. One thing is entrenched ! # in law, however: that there must be at least 150 days on daylight savings ! # time annually. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D ! Rule Zion 1989 only - Sep 3 0:00 0:00 S ! Rule Zion 1990 only - Mar 25 0:00 1:00 D ! Rule Zion 1990 only - Aug 26 0:00 0:00 S ! Rule Zion 1991 only - Mar 24 0:00 1:00 D Rule Zion 1991 only - Sep 1 0:00 0:00 S ! Rule Zion 1992 only - Mar 29 0:00 1:00 D ! Rule Zion 1992 only - Sep 6 0:00 0:00 S ! Rule Zion 1993 only - Apr 2 0:00 1:00 D ! Rule Zion 1993 only - Sep 5 0:00 0:00 S + # The dates for 1994-1995 were obtained from Office of the Spokeswoman for + # the Ministry of Interior, Jerusalem. There are no dates yet for 1996 and + # beyond so your guess is as good as theirs (those who are interested can + # call 972-2-701411 and ask for the spokeswoman). + + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S + Rule Zion 1994 only - Apr 1 0:00 1:00 D + Rule Zion 1994 only - Aug 28 0:00 0:00 S + Rule Zion 1995 only - Mar 31 0:00 1:00 D + Rule Zion 1995 only - Aug 27 0:00 0:00 S + # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 2:00 Zion I%sT ############################################################################### ----- end of patch ----- From: Ephraim Silverberg <ephraim(a)CS.HUJI.AC.IL> Subject: Re: bugs in entries for Israeli time zones? To: eggert(a)twinsun.com (Paul Eggert) Date: Sun, 5 Sep 93 11:12:02 EET In-Reply-To: <9309022041.AA15967(a)spot.twinsun.com>; from "Paul Eggert" at Sep 2, 93 1:40 pm > The latest version of Arthur David Olson's time zone package claims that > Israel switches from summer time to winter time on September 12. But Yitschak > Goldberg <yits(a)eandm.co.il> writes that it really switches on Sept. 5 this > year. Here is the current entry. Could you tell me what sort of corrections > are needed? I'd like to forward the fixes to Olson (and also to Richard > Stallman, the Emacs author). > > I'm interested in both the historical dates that the time zones changed, and > in the current rules (even if they are likely to change soon). Please don't > feel that you need to make detailed corrections to all this glop! I just > need to know what the current rules are and what the actual transitions > were between 1989 and now. Thanks for any help you can provide. Hi. Appended is the ZIC file with the most current information. Ephraim -------------------------------------------------------------------------------- # Zone Information Compiler (ZIC) File for the State of Israel (1989-2009) # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. # Each year they decide anew what havoc to wreak on the country. However, # there is a "supposed" set of rules which is subject to change depending # on the party the Minister of Interior, the size of the coalition # government, the phase of the moon and the direction of the wind. Hence, # changes may need to be made on a semi-annual basis. One thing is entrenched # in law, however: that there must be at least 150 days on daylight savings # time annually. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D Rule Zion 1989 only - Sep 3 0:00 0:00 S Rule Zion 1990 only - Mar 25 0:00 1:00 D Rule Zion 1990 only - Aug 26 0:00 0:00 S Rule Zion 1991 only - Mar 24 0:00 1:00 D Rule Zion 1991 only - Sep 1 0:00 0:00 S Rule Zion 1992 only - Mar 29 0:00 1:00 D Rule Zion 1992 only - Sep 6 0:00 0:00 S Rule Zion 1993 only - Apr 2 0:00 1:00 D Rule Zion 1993 only - Sep 5 0:00 0:00 S # The dates for 1994-1995 were obtained from Office of the Spokeswoman for # the Ministry of Interior, Jerusalem. There are no dates yet for 1996 and # beyond so your guess is as good as theirs (those who are interested can # call 972-2-701411 and ask for the spokeswoman). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1994 only - Apr 1 0:00 1:00 D Rule Zion 1994 only - Aug 28 0:00 0:00 S Rule Zion 1995 only - Mar 31 0:00 1:00 D Rule Zion 1995 only - Aug 27 0:00 0:00 S # These rules are probably wrong, but they are close approximations (usually # withing two weeks): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Apr 14 0:00 1:00 D Rule Zion 1996 only - Sep 8 0:00 0:00 S Rule Zion 1997 only - May 4 0:00 1:00 D Rule Zion 1997 only - Sep 28 0:00 0:00 S Rule Zion 1998 only - Apr 19 0:00 1:00 D Rule Zion 1998 only - Sep 13 0:00 0:00 S Rule Zion 1999 only - Apr 11 0:00 1:00 D Rule Zion 1999 only - Sep 5 0:00 0:00 S Rule Zion 2000 only - Apr 30 0:00 1:00 D Rule Zion 2000 only - Sep 24 0:00 0:00 S Rule Zion 2001 only - Apr 15 0:00 1:00 D Rule Zion 2001 only - Sep 9 0:00 0:00 S Rule Zion 2002 only - Apr 7 0:00 1:00 D Rule Zion 2002 only - Sep 1 0:00 0:00 S Rule Zion 2003 only - Apr 27 0:00 1:00 D Rule Zion 2003 only - Sep 21 0:00 0:00 S Rule Zion 2004 only - Apr 18 0:00 1:00 D Rule Zion 2004 only - Sep 12 0:00 0:00 S Rule Zion 2005 only - May 1 0:00 1:00 D Rule Zion 2005 only - Sep 25 0:00 0:00 S Rule Zion 2006 only - Apr 23 0:00 1:00 D Rule Zion 2006 only - Sep 17 0:00 0:00 S Rule Zion 2007 only - Apr 15 0:00 1:00 D Rule Zion 2007 only - Sep 9 0:00 0:00 S Rule Zion 2008 only - Apr 27 0:00 1:00 D Rule Zion 2008 only - Sep 21 0:00 0:00 S Rule Zion 2009 only - Apr 19 0:00 1:00 D Rule Zion 2009 only - Sep 13 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Israel 2:00 Zion I%sT

1 0