- tz - lists.iana.org

tzcode93g.tar.gz and tzdata93g.tar.gz
by ado Nov. 29, 1993

Nov. 29, 1993

The files tzcode93g.tar.gz and tzdata93g.tar.gz are now available for anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (128.231.16.1). Paul Eggert has provided a good deal of historic information (based on Shanks), and there are some code changes to deal with the buglets that crawled out in dealing with the new information. --ado

1 0

Iceland's timezone
by yata!eggert＠twinsun.com Nov. 11, 1993

Nov. 11, 1993

From: Adam David <adam(a)veda.is> To: wollman(a)uvm-gen.emba.uvm.edu Date: Sat, 6 Nov 1993 21:50:43 +0000 (GMT) Iceland has not changed timezone since 1900 and has not had Summer Time since quite a long time ago, probably before 1970. If you want exact dates for summertime that long ago, I will find this out for you. I'm working on a rewrite of `europe' with a large set of historical data. My current draft (see below) claims that Iceland changed its timezone in 1968. I've taken this claim from Thomas G. Shanks, The international atlas (3rd edition), San Diego: ACS Publications, Inc. (1991). If you have some better data, please let me know. It would be nice to know what time zone abbreviations were used before 1968, since Shanks doesn't say. In the following table I've made up the names `IST', `IDT', `RMT', and `LMT' for Iceland Standard Time, Iceland Daylight Time, Reykjavik Mean Time, and Local Mean Time respectively. # Iceland # # From Adam David <adam(a)veda.is> (November 6, 1993): # The name of the timezone in Iceland for system / mail / news purposes is GMT. # # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Iceland 1908 only - Jan 1 0:00 0 S Rule Iceland 1917 1918 - Feb 20 2:00 1:00 D Rule Iceland 1917 only - Oct 25 2:00 0 S Rule Iceland 1918 1919 - Nov 15 2:00 0 S Rule Iceland 1919 only - Feb 19 2:00 1:00 D Rule Iceland 1921 only - Mar 19 2:00 1:00 D Rule Iceland 1921 only - Jun 22 2:00 0 S Rule Iceland 1941 1942 - Mar Sat>=1 2:00 1:00 D Rule Iceland 1941 1942 - Jul 2 2:00 0 S Rule Iceland 1943 1946 - Mar Sun>=1 2:00 1:00 D Rule Iceland 1943 1948 - Oct Sun>=22 2:00 0 S Rule Iceland 1947 1962 - Apr Sun>=1 2:00 1:00 D Rule Iceland 1949 only - Oct 30 2:00 0 S Rule Iceland 1950 only - Oct 22 2:00 0 S # From Paul Eggert <eggert(a)twinsun.com> (November 10, 1993): # Shanks's ``1953 Oct 26'' is probably a typo for Oct 25. # Likewise, correct Shanks's ``1961 Oct 22'' to Oct 29. Rule Iceland 1951 1967 - Oct Sun>=23 1:00s 0 S Rule Iceland 1963 1968 - Apr Sun>=1 1:00s 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Atlantic/Iceland/Reykjavik -1:27:24 - LMT 1837 Jan 1 -1:28 - RMT 1908 Jan 1 -1:00 Iceland I%sT 1968 Oct 27 1:00s 0:00 - GMT # This link is for backward compatibility with the old naming convention. Link Atlantic/Iceland/Reykjavik Iceland

1 0

Re: Specifications for Iceland's timezone [forwarded]
by ado Nov. 9, 1993

Nov. 9, 1993

> From wollman(a)uvm-gen.EMBA.UVM.EDU Sat Nov 6 17:01:21 1993 > Return-Path: <wollman(a)uvm-gen.EMBA.UVM.EDU> > Received: from sadye.emba.uvm.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA20235; Sat, 6 Nov 93 17:01:19 EST > Received: by sadye.emba.uvm.edu id AA06301 > (5.65/1.23); Sat, 6 Nov 93 17:00:22 -0500 > Date: Sat, 6 Nov 93 17:00:22 -0500 > From: wollman(a)uvm-gen.EMBA.UVM.EDU > Message-Id: <9311062200.AA06301(a)sadye.emba.uvm.edu> > To: ado(a)elsie.nci.nih.gov > Subject: Specifications for Iceland's timezone > Status: RO > > One of the FreeBSD team members in Iceland reports the following > complaints with the default `Iceland' timezone as supplied in your > latest `europe' file: > > ------- Start of forwarded message ------- > From: Adam David <adam(a)veda.is> > To: wollman(a)uvm-gen.emba.uvm.edu > Subject: Re: New timezone code > Date: Sat, 6 Nov 1993 21:50:43 +0000 (GMT) > > [stuff deleted by me -GW] > > The problem with WET is that WET is used also in the British Isles, and > some systems might assume BST by default if they see "WET" during the summer > months. The name of the timezone in Iceland for system / mail / news purposes > is GMT. [...] > > > If Iceland has ever observed Summer Time or has changed time > > zones at any time in the past, I'd appreciate knowing about it, so we > > can update the files and send the corrections to Arthur David Olson. > > Iceland has not changed timezone since 1900 and has not had Summer Time > since quite a long time ago, probably before 1970. If you want exact dates > for summertime that long ago, I will find this out for you. > > [...] > ------- End of forwarded message ------- > > -GAWollman > > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman(a)emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. > uvm-gen!wollman | It is a bond more powerful than absence. We like people > UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant

1 0

possible time zone file syntax extension
by ado Nov. 5, 1993

Nov. 5, 1993

There's work in progress on adding historical information to time zone files. It might be useful to extend the syntax of "UNTIL" parts so that you could write something such as # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone This 0:00 - TST 1916 May 21 2:00s 0:00 Whatever T%sT 1968 Feb 18 2:00s->That where the "->That" on the final line means "after the UNTIL time, use whatever happens in Zone 'That'." This would both allow for more concise representation of historic information and allow a "-c" (or some other letter) flag to zic that would tell it to only compile "current" zones--zones that did NOT end with a line containing "->". If you have insights on whether this is the best thing to do, I'd love it if you'd share them with folks on the time zone mailing list. --ado

1 0

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