October 1996 - tz - lists.iana.org

Solaris multithreading and timezones
by Valery Aronov Oct. 22, 1996

Oct. 22, 1996

We are moving our software towards multithreading (SunOS 5.5.1). One of the many concerns is the MT-unsafety of tzset() function. It is said to be MT-unsafe in man pages. It is partly due to the keeping references to TZ in the environment variable, I guess. Our software needs to deal with more than one timezone in one process. The only way I know to implement it is to change the value of environment variable TZ and call tzset() every time I want to switch to a new timezone. External variables tzname and others also makes it problematic to maintain access to them: other vendors' software we are using might use their own policy of access. How is it possible to manage current zone information in MT-safe fashion? I would appreciate any help. Valery

3 3

c-common.c
by ado Oct. 18, 1996

Oct. 18, 1996

The file ftp://elsie.nci.nih.gov/pub/c-common.c is now available; this is a replacement for c-common.c in gcc (either 2.7.2 or 2.7.2.1) that does strftime format checking (with special warning for formats that generate two digits worth of years and thus may be especially subject to year 2000 challenges). If anyone has feedback before I ship it off to the GNU folk, I'd love it! --ado

3 3

[Karst Koymans: bin/1740: Setting TZ to unusual values c]
by Garrett Wollman Oct. 9, 1996

Oct. 9, 1996

I don't know whether this is a BSD-specific problem or exists in the current tzcode, but I figured I might forward it here in case it does. -GAWollman ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <199610082133.OAA28831(a)freefall.freebsd.org> X-Send-Pr-Version: www-1.0 X-Loop: FreeBSD.org Precedence: bulk From: Karst.Koymans(a)phil.ruu.nl Sender: owner-bugs(a)freebsd.org To: freebsd-gnats-submit(a)freebsd.org Subject: bin/1740: Setting TZ to unusual values crashes applications using localtime Date: Tue, 8 Oct 1996 14:33:13 -0700 (PDT) >Number: 1740 >Category: bin >Synopsis: Setting TZ to unusual values crashes applications using localtime >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 8 14:40:02 PDT 1996 >Last-Modified: >Originator: Karst Koymans >Organization: Utrecht University >Release: 960501 snapshot >Environment: >Description: Setting TZ to unusual values like "Europe" crashes all applications using the localtime routine. This is because the tzload routine happily opens any file, even directories, as valid timezone files. "Europe" happens to be a directory under /usr/share/zoneinfo. >How-To-Repeat: TZ=Europe date >Fix: >Audit-Trail: >Unformatted: ------- end -------

1 0

patch to zic.8 to document format of UNTIL field
by Paul Eggert Oct. 8, 1996

Oct. 8, 1996

From: "Rob Jones 4-6597 MR Sys" <jones(a)mr.med.ge.com> Date: Tue, 8 Oct 1996 12:23:18 -0500 In the tzdata files when the UNTIL field is just a year (without a month day) specified, does that mean up to and including that year, or just up to ? Somehow that didn't get documented. Here's a draft patch. In practice I use vague dates like `1967' when I don't know exactly when the rules changed, and a more precise time stamp like `1967 Jan 1 00:00' if I know that's the exact time -- even though both inputs mean the same thing to `zic'. =================================================================== RCS file: RCS/zic.8,v retrieving revision 1995.7 retrieving revision 1995.7.1.1 diff -c -r1995.7 -r1995.7.1.1 *** zic.8 1995/10/30 14:58:15 1995.7 --- zic.8 1996/10/08 18:31:38 1995.7.1.1 *************** *** 304,309 **** --- 304,312 ---- If this is specified, the time zone information is generated from the given GMT offset and rule change until the time specified. + The month, day, and time of day have the same format as the IN, ON, and AT + columns of a rule; trailing columns can be omitted, and default to the + earliest possible value for the missing columns. .IP The next line must be a .q continuation

1 0

Antarctic update
by Chris Carrier Oct. 8, 1996

Oct. 8, 1996

Ethan Dicks > INTERNET:erd@mcmsun5.mcmurdo.gov has informed me: >BTW, the data for the British Base Rothera is out of date. Last >year (1995) was the last winter-over season. It's now a summer only station.

1 0

Re: Recent changes to time zones reported by IATA
by Paul Eggert Oct. 6, 1996

Oct. 6, 1996

Date: Fri, 04 Oct 1996 19:34:39 -0500 (EST) From: Gwillim Law 919-852-4294 <LAW(a)encmail.encompass.com> I thought the tz mailing list would want to see these changes, and compare them to those reported by other sources. That is a very helpful contribution; thanks. I compared the IATA changes with the changes reported by other tz contributors, and have the following comments. Later, I'll send out a draft patch reflecting these comments, as well as all the other comments received so far. * Armenia stopped using DST this year, according to Edgar Der-Danieliantz <edd(a)AIC.NET> (1996-05-04). Did the IATA catch this change? * Azerbaijan data from the IATA disagrees with both Shanks and USNO. I guess that the IATA is right, and that we're missing some transitions between 1991 and 1996. Azerbaijan apparently enjoys the distinction of being the first Asian country to use the European Union's DST rules (including switching at 0100 UTC). * Brazil - You wrote: three states (Alagoas, Sergipe, and Tocantins) will begin using DST, probably on October 13, 1996. Could you give more details about this? The entries that you sent made it look like only the DST dates were adjusted. As far as I can tell from other sources, DST is observed uniformly in Brazil, even in the far north where the hemisphere is wrong. Perhaps these states used to be 2 hours behind UTC, and are now 3? This would agree with the map in <URL:http://www.bancobrasil.com.br/bbtur.ing/bbttime.htm>, but so far I've discounted that map, not only because no other sources have UTC-2 Brazilian mainland, but also because its line between UTC-2 and UTC-3 is suspiciously straight. Also, some of the beginning and end dates for DST were adjusted by a week. You gave the change only for BR1; were the dates also changed for other zones in Brazil? It would be odd if the different parts of Brazil had different DST dates. All the Brazilian transitions that we know of since 1989 are consistent with the rules Oct Sun>=10 00:00 and Feb Sun>=10 00:00; I'll propose a change to the tz rules accordingly. * Iran The tz database had Iran not using DST since 1980. For lack of better info I'll assume they readopted DST in 1996. Iran now apparently moves its clocks approximately on the equinoxes -- I think it's the only country to do this. * Kazakhstan - you wrote: Kazakhstan, formerly unified on UTC+6 with DST, will divide into three zones. They will observe UTC+4, 5, and 6, all with DST. The western zone (UTC+4) consists of Aktau, Atyrau, and Uralsk oblasts, and the central zone is Aktyubinsk oblast. Andrew Evtichov <evti(a)chevron.com> (1996-04-13) wrote that Kazakhstan has had multiple time zones for quite some time: at least 2 ``always'' and 3 now. I'd guess that the IATA SSIM is just catching up with this fact. Unfortunately, I misparsed his earlier message and thought that Kazakhstan had just 2 time zones now; he actually wrote that it has 3. I'll add a new zone for Aqtobe (formerly Aktyubinsk) and rename Asia/Aktau to Asia/Aqtau since `Aqtau' name seems to be the usual English rendering of the Kazakh name. * Lebanon. Lebanon returned from DST to Standard Time on September 28, 1996, instead of October 26 as previously announced. Shanks has Lebanon switching on May 1 and Oct 16 every year. Evidently that has changed more than once since 1991. For lack of better info I'll propose a patch so that Lebanon switches on the last Sunday in March and the last Sunday in September, starting 1996. * Libya if I'm right, the first actual time change was on September 30, 1996, when clocks were set back an hour. That sounds right: since 1959, Libya has switched back and forth between straight UTC+2 and UTC+1 with DST. * Mexico - the IATA and tz agree. * Mongolia The IATA says that changes occur at local midnight, whereas Shanks says they occur at 02:00 standard time. Also, the IATA says the fall transition is the 4th Friday (!) in October, whereas tz said it was the last Sunday in September. I'll assume that the IATA is right, and that the rules changed in 1996, but we're undoubtedly missing some other changes between 1985 and 1995. * Paraguay Paraguay will return from DST to Standard Time on March 1, 1997, instead of February 23 as previously announced. Shanks has this transition occuring on April 1. For lack of better info, I'll assume they changed the rules from April 1 to March 1 in 1996. * Portugal Portugal (excluding Azores and Madeira) has switched from UTC+1 to UTC (both using DST). There's no indication of when the change occurred. Martin Bruckmann <martin(a)ua.pt> (1996-02-29) reported that the change occurred this spring, by Portugal not changing its clocks. * Russia Russia's fall transition used to be the last Sunday in September, but it's changed to the last Sunday in October (at 02:00 standard time, as before). Did the IATA catch this change? Presumably this change also applies to Kazakhstan (I just checked the ricc.kz time server in Alma-Ata, and they're still on DST) as well as Kirgizstan. While we're on the subject, in the absence of any better info, the current tz database assumes that Belarus, Estonia, Latvia, Lithuania, and Moldova are moving their clocks on the last Sunday in October at 02:00 standard time, starting this year (in previous years they used September). Since the EU, Russia, and Ukraine are all known to be making a similar switch, it wouldn't be surprising if the other countries are switching too; but we have no info. * Sri Lanka Sri Lanka has changed from UTC+5:30 to UTC+6:30 year-round. There's no indication of when the change occurred. It occurred 1996-05-25 00:00 local time, according to LankaWeb <URL:http://www.virtual-pc.com/lankaweb/news/items/240596-2.html>. * Ukraine Ukraine will begin and end DST at 3:00 am local time, rather than midnight as it used to. (The data make it clear that this is 3:00 local standard time.) For most of Ukraine, this makes sense, since it's the EU rules. However, for Crimea, it doesn't make sense, since it's neither the EU rules (which operate at 4:00 local standard time) nor the Moscow rules (which operate at 2:00 local standard time). Apparently the Ukrainians and the Crimeans are having a little tussle; there was a news story about this by Itar-Tass <URL:http://www.itar-tass.com/tassnews.htm> at 09-18 00:43 entitled ``Crimea ponders over problem of time zone'' but unfortunately I don't have a copy of the story. For now I'll assume Crimea was using Moscow rules until this year, and is as IATA reports afterwards. Shanks says all of Ukraine switches at 2:00 standard time, not midnight. For lack of better info I'll assume that this was true through 1995.

1 0

Spring Forward, Fall Back -- but not just yet
by Monty Solomon Oct. 6, 1996

Oct. 6, 1996

Excerpt from RISKS DIGEST 18.50 ------------------------------ Date: Tue, 1 Oct 1996 12:02:10 +0200 From: minow(a)apple.com Subject: Spring Forward, Fall Back -- but not just yet The biannual daylight savings time confusion began this weekend in Sweden. When Sweden joined the EU (Common Market), it changed the fall changeover from the last weekend in September to the last weekend in October to conform with the rest of Europe. Unfortunately, a few hundred thousand Windows '95 machines were not informed of the changeover and, followed pre-programmed instructions, switched on the old schedule. This is, of course, one small example of a much more difficult problem: there is no obvious way to pre-program daylight savings time changeover in a way that is sufficiently robust to withstand government intervention. (My favorite example is Arizona, where federal land changes, but state land remains on mountain standard time year around.) Martin Minow minow(a)apple.com ------------------------------

1 0

Antarctic Time
by erd＠mcmsun5.mcmurdo.gov Oct. 6, 1996

Oct. 6, 1996

Howdy all, Ethan Dicks here. I'm a computer tech at McMurdo Station who has been sleuthing why my clock on my OpenWin desktop didn't display the correct local time this morning (N.Z. just changed to DST about 20 hours ago), and dug up this mailing list from the docs in the zoneinfo source. It appears as if I've just missed most of the fun of verifying Antarctic time, but I did notice that Palmer Station is not represented in the recently released tables... I am researching the history of Palmer's timezone; for the past few years (I don't know how many yet), it keeps the same time as Punta Arenas, Chile, because, just like us and the South Pole, that's the other end of their supply line. Palmer is located at 64.8S by 64.1W, i.e., AQ -6448-6406 Antarctica/Palmer Palmer Station, Anvers Island A footnote on the McMurdo/South Pole timezone issue - our wall clocks and wristwatches are set to N.Z. time (with DST, when appropriate). Our UNIX machines are set to UTC to simplify timestamps on collected data. Desktop machines (Macs and PCs) are set to wall time, however. Please include me on this list for the time being. For the summer season at least, I'm taking care of a bunch of UNIX machines and would like the xclocks to display the correct local time. -ethan -- Ethan Dicks erd(a)infinet.com |"Getting up, that is a problem. I've always had McMurdo Station, Antarctica | a hard time getting up when it's dark outside." erd(a)csec.mcmurdo.gov |"But in space, it's always dark." http://www.infinet.com/~erd/ |"I know...I know" - Sinclair & Ivanova, Babylon 5

1 0

Re: Recent changes to time zones reported by IATA
by kuhn＠cs.purdue.edu Oct. 4, 1996

Oct. 4, 1996

In message <8239341304101996/A31085/GLVC12/11AA23622600*@MHS>, Gwillim Law 919- 852-4294 wrote: > Twice a year, the International Air Transport Association (IATA) issues > a publication containing worldwide time zone data. It's called the > Standard Schedules Information Manual (SSIM). Its main purpose is to > define message formats for airlines to use when communicating their > schedules. The time zone information is apparently submitted by member > airlines, and represents the data those airlines intend to use in their > own schedules. Appendix F of the SSIM contains the time zone data. Sounds very useful. Do you know any contact address where one could subscribe this publication and what the subscription fee is? Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

2 1

FREE registration in over 400 indexes!
by RHill＠TheHost.com Oct. 4, 1996

Oct. 4, 1996

Hi, I saw your site at http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html/, it looks good. Register it FOR FREE in over 400 Internet indexes and directories at http://www.CentralRegistry.com/ (just click the "free" button). I used it for my site and it worked great, traffic soared! Rusty J. Hill RHill(a)TheHost.com

1 0