- tz - lists.iana.org

Re: Timezone rule change in Europe [forwarded from Dik Winter]
by Dik.Winter＠cwi.nl Dec. 3, 1993

Dec. 3, 1993

> Has anyone got precise details of the dates? i.e last sunday in october, or > last sunday after 23rd October (like uk) The paper was a bit unclear about that; the text was conflicting. On the one hand it talked about the current UK rule, on the other hand it talked about the last sunday in October. But I presume the rule now valid in the UK will be adopted by the remainder of the EU. So that would be first sunday after 23rd October. I will report about it when I know more. dik

1 0

Re: Timezone rule change in Europe [forwarded from Dik Winter]
by Glenn.Wright＠UK.Sun.COM Dec. 3, 1993

Dec. 3, 1993

Has anyone got precise details of the dates? i.e last sunday in october, or last sunday after 23rd October (like uk) Glenn. > > The ministers of transport of the European Union (formerly European > Community) have decided that by 1997 change from summer time to > winter time will be made by the end of october instead of the end > of september. This will bring the remainder of the EU in line with > the current rule in the United Kingdom and Ireland. It is to be expected > that other European countries will follow. [This according of my > paper of todaty, December 1.] > > (The European Union consists of: Netherlands, Belgium, Luxembourg, > France, Germany, Italy, United Kingdom, Ireland, Danmark, Spain, > Portugal and Greece.)

1 0

Timezone rule change in Europe [forwarded from Dik Winter]
by ado Dec. 2, 1993

Dec. 2, 1993

> From daemon(a)ncifcrf.gov Thu Dec 2 13:51:20 1993 > Return-Path: <daemon(a)ncifcrf.gov> > Received: from fcs280s.ncifcrf.gov by elsie (4.1/SMI-4.1) > id AA12625; Thu, 2 Dec 93 13:51:19 EST > Received: by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA04025; Thu, 2 Dec 93 13:43:34 GMT > Received: from charon.cwi.nl by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA04003; Thu, 2 Dec 93 13:43:28 GMT > Received: from boring.cwi.nl by charon.cwi.nl with SMTP > id AA02005 (5.65b/3.12/CWI-Amsterdam); Wed, 1 Dec 1993 22:07:42 +0100 > Received: by boring.cwi.nl > id AA12403 (4.1/2.10/CWI-Amsterdam); Wed, 1 Dec 93 22:07:42 +0100 > Date: Wed, 1 Dec 93 22:07:42 +0100 > From: Dik.Winter(a)cwi.nl > Message-Id: <9312012107.AA12403.dik(a)boring.cwi.nl> > To: ado(a)ncifcrf.gov > Subject: Timezone rule change in Europe > Status: RO > > The ministers of transport of the European Union (formerly European > Community) have decided that by 1997 change from summer time to > winter time will be made by the end of october instead of the end > of september. This will bring the remainder of the EU in line with > the current rule in the United Kingdom and Ireland. It is to be expected > that other European countries will follow. [This according of my > paper of todaty, December 1.] > > (The European Union consists of: Netherlands, Belgium, Luxembourg, > France, Germany, Italy, United Kingdom, Ireland, Danmark, Spain, > Portugal and Greece.) > > dik > -- > dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland > home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik(a)cwi.nl

1 0

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