- tz - lists.iana.org

Re: CORRECTION: April 18 in CM of OW3
by guy＠auspex.com March 29, 1993

March 29, 1993

>A week ago I asked: > >>Calendar Manager on Open window 3 has a bug. April 18 cannot be scheduled. >>Try it on your machine and return to me if you find a way to overcome it. > >Thank you all for your answers in which you said that such a problem >doe's not exist on your machine. Well, the problem found in file: > >/usr/share/lib/zoneinfo/asia > >April 18, 1993 was one line in that file which indicates the day of >summer time in Israel. > >Rule Zion 1993 only - Apr 18 00:00 1:00 D > >This line was fixed to: > >Rule Zion 1993 only - Apr 1 23:00 1:00 D > > >and after running 'zic asia', the problem disappear. > >Thanks > >-- > /\/\/\ E-mail: joel(a)mcil.comm.mot.com [ Motorola Communications Israel ] >/ Joel \ X.400 CJN003 [ Fixed & Data Products Division ] >\ Nahum/ Phone: +972 (3) 565-8479 [ 3 Kremenetski Street ] > \____/ Fax: +972 (3) 565-8356 [ 61 250 Tel-Aviv, ISRAEL ] Are you saying that Summer Time begins on April 1, not April 18, this year? If so, it'd cause problems with more than *just* the Calendar Manager, as the compiled time-zone files are used throughout the system. Are there any other errors in the rules for Israel in the "asia" file? We (the Timezone Cabal) would like to have the data in all the files be as correct as possible, so please send us any corrections you have.... (Timezone Caballeros: Should I post a followup and/or a note to "comp.sys.sun.admin" and possibly also "comp.unix.bsd" and "comp.unix.sys5.r4", requesting that *all* fixes to the timezone files be sent to "tz(a)elsie.nci.nih.gov"?)

1 0

Leap second announcement; updated "leapsecond" file
by ado Feb. 2, 1993

Feb. 2, 1993

A leap second announcement from the USNO is attached; as well as a shar-format version of an updated "leapseconds" file. You'll now find "tzdata93b.tar.Z" on elsie.nci.nih.gov; the only change to it from "tzdata93.tar.Z" is the updated "leapseconds" file. --ado > From ntp-relay(a)ni.umd.edu Tue Feb 2 14:49:18 1993 > Return-Path: <ntp-relay(a)ni.umd.edu> > Received: from ni.umd.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA02852; Tue, 2 Feb 93 14:49:14 EST > Received: by ni.umd.edu id AA06039 > (5.65c/IDA-1.4.4 for ntp-list); Tue, 2 Feb 1993 14:21:15 -0500 > Received: from unbmvs1.csd.unb.ca by ni.umd.edu with SMTP id AA06030 > (5.65c/IDA-1.4.4 for <NTP(a)NI.UMD.EDU>); Tue, 2 Feb 1993 14:20:50 -0500 > Received: from unbmvs1.csd.unb.ca by UNBMVS1.csd.unb.ca (IBM MVS SMTP V2R1) > with BSMTP id 3951; Tue, 02 Feb 93 15:20:05 AST > Received: by UNBMVS1 (Mailer 15.14) id 5634; Tue, 02 Feb 93 15:18:57 AST > Date: Tue, 02 Feb 93 15:18:57 AST > From: LANG(a)unb.ca > To: "NTP List" <NTP(a)NI.UMD.EDU> > Subject: Leap Second Announcement from USNO > Message-Id: <ID3951.D930202.T151859.LANG(a)unb.ca> > Status: R > > > -------------------- Start of forwarded message -------------------- > Received: from UNBMVS1(MAILER) by UNBMVS1(Mailer 15.14) id 3871 > for LANG@UNBMVS1; Tue, 02 Feb 93 15:11:45 AST > Received: by UNBMVS1 (Mailer 15.14) id 2636; Tue, 02 Feb 93 15:09:43 AST > Date: Tue, 02 Feb 93 15:09:43 AST > From: <CANSPACE(a)UNB.CA> > To: <lang@UNBMVS1> > Received: from unb.ca by UNBMVS1.csd.unb.ca (IBM MVS SMTP V2R1) with TCP; > Tue, 02 Feb 93 15:08:16 AST > Received: from by unb.ca (4.1/SMI-4.1-921218.08:05) > id AZ01277; Tue, 2 Feb 93 15:08:27 AST > Received: from NEPTUNE.CSD.UNB.CA by NEPTUNE.CSD.UNB.CA (IBM VM SMTP V2R1) > with BSMTP id 5064; Tue, 02 Feb 93 15:03:20 AST > Received: from UNBVM1.BITNET (NJE origin LISTSERV@UNBVM1) by NEPTUNE.CSD.UNB.CA > (LMail V1.1b/1.7e) with BSMTP id 5057; Tue, 2 Feb 1993 14:58:41 -0400 > Comments: Original-Date: Tue, 2 Feb 1993 14:54:47 AST > X-Reply-To: Richard Langley <lang(a)JUPITER.SUN.CSD.UNB.CA> > X-Sender: Canadian Space Geodesy Forum <CANSPACE(a)UNBVM1.BITNET> > X-From: Richard Langley <lang(a)JUPITER.SUN.CSD.UNB.CA> > Subject: Leap Second Announcement from USNO > X-To: CANSPACE(a)unb.ca > X-To: Multiple recipients of list CANSPACE <CANSPACE(a)UNBVM1.BITNET> > Sender: <CANSPACE(a)UNB.CA> > Message-ID: <ID3871.D930202.T150943.CANSPACE(a)UNB.CA> > > File SER14 -- <930201.1735> > > > > U.S. NAVAL OBSERVATORY > WASHINGTON, DC 20392-5420 > > February 1, 1993 > No. 55 > > TIME SERVICE ANNOUNCEMENT SERIES 14 > > UTC TIME STEP > > 1. The International Earth Rotation Service (IERS) has announced the > Introduction of a time step to occur at the end of June 1993. > > 2. Coordinated Universal Time (UTC) will be retarded by 1.0s so that the > sequence of dates of the UTC markers will be: > > 1993 June 30 23h 59m 59s > 1993 June 30 23h 59m 60s > 1993 July 01 0h 0m 0s > > 3. The difference between UTC and International Atomic Time TAI is: > > from 1992 Jul 1, 0h UTC, to 1993 Jul.1, 0h UTC: TAI-UTC = +27s > from 1993 Jul 1, 0h UTC, until further notice: TAI-UTC = +28s > > 4. The insertion of one leap second will be evident by the change of > sign of the DUT1 correction which will become positive. Extrapolated > values of DUT1 are distributed weekly in the IERS Bulletin A (Time > Service Announcement Series 7). > > 5. All coordinated time scales will be affected by this adjustment. > However, the Loran-C, GPS and OMEGA systems will not be adjusted > physically. Tables of Coincidence (Time Service Announcement Series 9) > will be issued for Loran-C. For GPS, the leap second correction > contained within the UTC data of subframe 4, page 18 of the navigation > message transmitted by the satellite will change. > > Before the leap second > > GPS-UTC = +8s (i.e., GPS is ahead of UTC by eight seconds). > > After the leap second > > GPS-UTC = +9s (i.e., GPS will be ahead of UTC by nine seconds). > > The OMEGA Reference Ephoch (ORE) will change - that is, from 1 July > 1993 (after the leap second) the OMEGA system will operate with the > the beginning of segment one on seconds 42, 52, 02, 12, 22, and 32 of > each minute. > > GERNOT M. R. WINKLER > Director > Time Service Department > > via: > ============================================================================== > Richard B. Langley Internet: LANG(a)UNB.CA or SE(a)UNB.CA > Geodetic Research Laboratory BITnet: LANG@UNB or SE@UNB > Dept. of Surveying Engineering Phone: (506) 453-5142 > University of New Brunswick FAX: (506) 453-4943 > Fredericton, N.B., Canada E3B 5A3 Telex: 014-46202 > ============================================================================== > --------------------- End of forwarded message --------------------- : To unbundle, sh this file echo file 'leapseconds' >&2 cat >'leapseconds' <<'End of leapseconds' # @(#)leapseconds 7.6 # Allowance for leapseconds added to each timezone file. # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is GMT # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S Leap 1976 Dec 31 23:59:60 + S Leap 1977 Dec 31 23:59:60 + S Leap 1978 Dec 31 23:59:60 + S Leap 1979 Dec 31 23:59:60 + S Leap 1981 Jun 30 23:59:60 + S Leap 1982 Jun 30 23:59:60 + S Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S Leap 1989 Dec 31 23:59:60 + S Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S End of leapseconds exit

1 0

End of Rio hiccup
by ado Feb. 2, 1993

Feb. 2, 1993

Again forwarded from comp.protocols.time.ntp. Since the article does not report just when the mayor turned the watch back, I'll forego making a Hawaii-style change to the southamerica file. --ado > From emv(a)msen.com Tue Feb 2 12:43:49 1993 > Path: nih-csl!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!usc!sdd.hp.com!nigel.msen.com!emv > From: emv(a)msen.com (Edward Vielmetti) > Newsgroups: comp.protocols.time.ntp > Subject: Re: [brazil-time] rio de janeiro asks 'what time is it ?' > Message-ID: <1kmbt3INN36j(a)nigel.msen.com> > Date: 2 Feb 93 17:43:49 GMT > References: <1kkdseINNn87(a)nigel.msen.com> > Distribution: inet > Organization: Msen, Inc. -- Ann Arbor, Michigan > Lines: 29 > NNTP-Posting-Host: garnet.msen.com > X-Newsreader: TIN [version 1.1 PL8] > > Edward Vielmetti (emv(a)msen.com) wrote: > : Clock watchers take note... > > Ah, the time crisis in Brazil has passed (this also from REUTER). > > AM-BRAZIL-TIME 1STLD > RIO MAYOR RELUCTANTLY GIVES UP EXTRA HOUR OF DAYLIGHT > > (Eds: updates) > RIO DE JANEIRO, Brazil, Reuter - The mayor of Rio has > reluctantly agreed to set the city's clocks back one hour, > ending his defiance of a federal regulation to end summer > daylight saving time. > Mayor Cesar Maia turned his own watch back one hour Monday > after meeting Brazilian President Itamar Franco. > ``Now the Rio mayor and the president's watches are set for > the same time,'' Maia said. > He had ordered city workers to continue on the summer > schedule until Feb. 28, saying Rio's tourist industry needed the > extra hour of daylight. > But Rio banks, businesses, airports, bus stations, stock > market and major companies operated by the federal government's > time -- three hours behind Greenwich Mean Time-- causing great > confusion. > REUTER > > Edward Vielmetti, vice president for research, Msen Inc. emv(a)Msen.com > Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)

1 0

Local time hiccup in Brazil
by ado Feb. 2, 1993

Feb. 2, 1993

The attached from comp.protocols.time.ntp. --ado > From emv(a)msen.com Mon Feb 1 19:05:20 1993 > Path: nih-csl!darwin.sura.net!newsserver.jvnc.net!yale.edu!nigel.msen.com!emv > From: emv(a)msen.com (Edward Vielmetti) > Newsgroups: comp.protocols.time.ntp > Subject: [brazil-time] rio de janeiro asks 'what time is it ?' > Message-ID: <1kkdseINNn87(a)nigel.msen.com> > Date: 2 Feb 93 00:05:20 GMT > Distribution: inet > Organization: Msen, Inc. -- Ann Arbor, Michigan > Lines: 50 > NNTP-Posting-Host: garnet.msen.com > X-Newsreader: TIN [version 1.1 PL8] > > Clock watchers take note... > > [ Article crossposted from msen.reuters.international ] > [ Posted on 1 Feb 1993 13:50:34 -0500 ] > > AM-BRAZIL-TIME > RIO DE JANEIRO ASKS 'WHAT TIME IS IT ?' > > RIO DE JANEIRO, Brazil, Reuter - Residents of Rio de Janeiro > woke up Monday wondering what time it is. > The confusing clock situation arose when Rio Mayor Cesar > Maia defied a Brazilian government regulation to end summer's > daylight savings time Sunday and turn the clocks back an hour. > But Maia, saying Rio's tourism industry needs the extra hour > of daylight that daylight savings time provides, said the city > government and everyone and everything associated with it would > stick with the summertime time schedule until Feb. 28. > ``I am not going to turn my clock back, nor will the clocks > controlled by the city be turned back,'' Maia was quoted as > saying in the Jornal do Brasil newspaper Sunday. > Rio's banks, most businesses, airports, bus stations and the > stock market are abiding by the federal government's time. > Maia said Rio de Janeiro's tourism industry would be hurt by > moving the clocks back in the middle of the Southern > Hemisphere's summer. > ``The mayor said the jobs of 30,000 people depend on this > extra hour of sunlight, when residents and tourists stay on the > streets and beaches spending money and having fun,'' the > spokesman said. > Maia's decree, which does not apply to the city's suburbs, > has left most residents wondering whether they should begin > wearing two watches. > A spokeswoman for the business owners association said Rio > stores and shopping centers were using standard time on Monday, > but it was still not clear what they would do on Tuesday. > ``The official schedule in Rio is the national standard > time. The decree does not impose the summer schedule, but rather > suggests that businesses, services and industry operate on > summer's time,'' said the mayor's spokesman, adding that Rio's > public clocks will be reset to national standard time. > Maia was to meet President Itamar Franco later Monday to > discuss the time situation, among other things. > At least for the meeting, the mayor will have to think > standard time. The meeting is scheduled for 3:30 p.m. federal > government time, the spokesman said. > REUTER > > Edward Vielmetti, vice president for research, Msen Inc. emv(a)Msen.com > Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)

1 0

tzcode93.tar.Z and tzdata93.tar.Z
by ado Jan. 8, 1993

Jan. 8, 1993

A new version of the time zone stuff is available for anonymous ftp from elsie.nci.nih.gov (128.231.16.1), in the ~ftp/pub directory: -r--r--r-- 1 ado 91953 Jan 8 07:01 tzcode93.tar.Z -r--r--r-- 1 ado 44313 Jan 8 07:01 tzdata93.tar.Z At kre's suggestion, the package has been split in two--a code piece (which also includes documentation) that's only of use to folks who want to recompile things and a data piece useful to anyone who can run "zic". The new version has a few changes to the data files, a few portability changes, and an off-by-one fix (with thanks to Tom-Karzes(a)deshaw.com for providing a description and a solution). --ado

1 0

elsie.nci.nih.gov:~ftp/pub/tz92c.tar.Z
by ado Nov. 22, 1992

Nov. 22, 1992

The fallout from the latest round of DST transitions is available as elsie.nci.nih.gov:~ftp/pub/tz92c.tar.Z There are changes for Portugal, Saskatchewan, and "Pacific-New"; there's also a change to "zic.c" that makes it portable to more systems. Any ideas for how to handle things are welcome; they are best mailed to tz(a)elsie.nci.nih.gov so that they can get wide consideration. --ado

2 1

Re:East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Nov. 6, 1992

Nov. 6, 1992

> Date: 06 Nov 1992 16:13:04 -0600 (CST) > From: jones(a)skdad.usask.ca (W. Jones) > Subject: Re: East-Saskatchewan -> Saskatchewan > To: ado(a)elsie.nci.nih.gov > Cc: eggert(a)twinsun.com, hardie(a)herald.usask.ca, henry(a)zoo.utoronto.ca, > peachey(a)pixar.com, tastad(a)sklib.usask.ca > ... > > Earlier I wrote: > >The most likely answer is that no-DST was adopted province-wide on some date > >(say in the late 1960s), and before that was subject to community variations. > >One thing I might ask is what precision you consider important for describing > >earlier practice. (Whatever the date, there were certainly no Unix systems > >running in affected areas.) > > The approximate answer below is based on information I got from our law > library, the provincial archives, and the provincial Community Services > department. A precise history would require digging through newspaper > archives, and since you didn't say what you wanted, I didn't bother. > > Saskatchewan is split by a time zone meridian (105W) and over the years > the boundary became pretty ragged as communities near it reevaluated > their affiliations in one direction or the other. In 1965 a provincial > referendum favoured legislating common time practices. > > On 15 April 1966 the Time Act (c. T-14, Revised Statutes of Saskatchewan > 1978) was proclaimed, and established that the eastern part of > Saskatchewan would use CST year round, that districts in northwest > Saskatchewan would by default follow CST but could opt to follow Mountain > Time rules (thus 1 hour difference in the winter and zero in the summer), > and that districts in southwest Saskatchewan would by default follow > MT but could opt to follow CST. > > It took a few years for the dust to settle (I know one story of a town > on one time zone having its school in another, such that a mom had to > serve her family lunch in two shifts), but presently it seems that only > a few towns on the border with Alberta (e.g. Lloydminster) follow MT > rules any more; all other districts appear to have used CST year round > since sometime in the 1960s. > > Here's how I would summarize things. Establish a "Saskatchewan" CST time > zone, and note that it officially exists as of 15 April 1966. Any current > exceptions can put themselves in the "Mountain" zone, since those are the > rules they follow. Any past exceptions can be forgotten, since that's > what those who live here have done.

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> From: henry(a)zoo.toronto.edu > Date: Wed, 28 Oct 92 11:58:53 EST > Subject: Re: East-Saskatchewan -> Saskatchewan > To: ado(a)elsie.nci.nih.gov, eggert(a)twinsun.com > Cc: jones(a)skorpio.usask.ca (W. Jones), peachey(a)pixar.com > > >... Anyway, I agree with Darwyn that the situation since around the > >Unix epoch is CST year round for the whole province, not just some flakes > >in the eastern corner. > > Actually, I think the province *is* split, but it's not an eastern corner > vs. everybody else. I grew up in Saskatoon, which is roughly central (and > one of the two major cities), and as a kid (1960s) I never knew DST *existed*. > (DST still strikes me as strange and stupid, actually.) Saskatoon, and at > least the immediate vicinity, has been on CST year round for a long time. > > On the other hand, other areas of the province haven't been... I first > became aware of DST when visiting relatives in Fort Qu'Appelle, a small > town south and east of Saskatoon. That was mid-late 1960s. I haven't been > back there for a long time and don't know the current situation. > > Henry Spencer at U of Toronto Zoology > henry(a)zoo.toronto.edu utzoo!henry

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 15:40:24 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272340.AA13750(a)farside.twinsun.com> > To: ado(a)elsie.nci.nih.gov > ... > Subject: East-Saskatchewan -> Saskatchewan > ... > W. Jones works in Saskatoon, which (according to my dictionary) is in Central > Saskatchewan. Assuming he's correct about the clocks in his immediate > neighborhood, at least the `East-' in `East-Saskatchewan' must be wrong. > Of your sources, Bur and Peachey (another Saskatchewan resident) agree with > Jones, whereas Devine disagrees. Given the current evidence, I'd tend to go > with Bur, Jones, and Peachey -- after all, two of them live there.

1 0

Historical material on Saskatchewan
by ado Oct. 28, 1992

Oct. 28, 1992

I've attached some historical material on the original of East-Sask. --ado > From seismo!mit-eddie!spock.ee.mcgill!mannix.decnet!burj Fri Mar 6 08:58:05 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA13319; Fri, 6 Mar 87 08:57:48 EST > Received: by seismo.CSS.GOV (5.54/1.14) > id AA12469; Fri, 6 Mar 87 05:13:00 EST > Received: by harvard.harvard.edu; Fri, 6 Mar 87 05:13:14 EST > Received: by EDDIE.MIT.EDU (5.31/4.7) id AA25906; Fri, 6 Mar 87 05:12:12 EST > Received: from spock by musocs.cs.mcgill id aa00376; 6 Mar 87 4:40 EST > Received: from Mannix.UdeM (mannix.ARPA) by spock.EE.MCGILL (4.12) > id AA00684; Fri, 6 Mar 87 04:50:05 est > Date: Thu, 5 Mar 87 03:37:17 est > From: Justin Bur <seismo!harvard!spock.ee.mcgill!mannix.decnet!burj> > Message-Id: <8703050837.AA00977(a)Mannix.UdeM> > Poslfit: poslfit > To: musocs!tz%elsie.uucp > Subject: DST in Saskatchewan, Canada > > The province of Saskatchewan, normally in the Central time zone, > has not used daylight savings time for the past several years. > I think there was some talk of using it for the first time this > year, but I don't remember. I also don't know if DST has never > been used in Sask. or if it used to be used some time ago: my > source is the national radio schedules of the Canadian Broadcasting > Corporation, and my subscription started in 198?. I will send more > precise information if I can find it, but it would probably be best > to find a local source of information. I *think* sask.uucp is the > University of Saskatchewan; I don't have a uucp map handy. > > Justin Bur -- Universite de Montreal > <burj(a)iros1.uucp> seismo!think!mosart!mcgill-vision!iros1!burj > > From seismo!ihnp4!sask!skorpio.UUCP!peachey Mon Mar 16 21:59:53 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA00162; Mon, 16 Mar 87 21:59:38 EST > Received: from cbosgd.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP > id AA13632; Mon, 16 Mar 87 17:31:56 EST > Received: by cbosgd.MIS.OH.ATT.COM (smail2.2) > id AA07856; 16 Mar 87 17:31:04 EST (Mon) > Received: by ihnp4.ATT.COM id AA03508; 16 Mar 87 15:10:26 CST (Mon) > Received: by sask.USask.UUCP (4.12/USask-2.01/9-Feb-87) > id AA24861; Mon, 16 Mar 87 15:03:37 cst > Received: by skorpio.USask.UUCP (4.12/USask-2.0/17-Dec-86) > id AA02480; Mon, 16 Mar 87 14:54:46 cst > Date: Mon, 16 Mar 87 14:54:46 cst > From: seismo!ihnp4!skorpio!peachey (Darwyn Peachey) > Message-Id: <8703162054.AA02480(a)skorpio.USask.UUCP> > To: elsie!tz > Subject: northamerica timezones & Saskatchewan > Cc: peachey > > > If I am reading your "northamerica" (version 3.1) timezone file correctly, > it appears to be inaccurate concerning the province of Saskatchewan in > Canada. You seem to assume that all of Canada observes the DST rules. > In fact, Saskatchewan is always on standard time and has been for several > years (up to 20, I'd guess). To be more precise, we are always on daylight > time, since we are geographically in the Mountain zone, but we use Central > Standard Time year round! Thus, there is always a four hour time difference > between us and Hawaii (whereas the temperature difference varies from > -130F to +20F). > > Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909 > > From seismo!nbires!vianet!devine Tue Mar 17 14:33:32 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA03816; Tue, 17 Mar 87 14:33:18 EST > From: seismo!nbires!vianet!devine > Received: from nbires.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP > id AA14658; Tue, 17 Mar 87 12:36:49 EST > Date: Tue, 17 Mar 87 12:36:49 EST > Message-Id: <8703171736.AA14658(a)seismo.CSS.GOV> > To: elsie!tz > Subject: Re: northamerica timezones & Saskatchewan > Cc: devine > > Darwyn Peachey peachey(a)sask.UUCP writes: > > If I am reading your "northamerica" (version 3.1) timezone file correctly, > > it appears to be inaccurate concerning the province of Saskatchewan in > > Canada. You seem to assume that all of Canada observes the DST rules. > > In fact, Saskatchewan is always on standard time and has been for several > > years (up to 20, I'd guess). To be more precise, we are always on daylight > > time, since we are geographically in the Mountain zone, but we use Central > > Standard Time year round! > > The information I have found on Saskatchewan Daylight Time is this: > > 1962-1971 Variable (each locality may have done something different) > but it seems to be last Sunday in April to last Sunday > in October (September in 1960-1) > > 1972-present? Observed in entire province except in the far-eastern > part (that part is on Central Standard time all year) > The western part is on the last Sunday in April to > last Sunday in October schedule > > I don't know where the machine 'skorpio' is but I infer that it is in > the Eastern part of Saskatchewan. Does anyone have access to an official > publication of Canada that describes DST? Does such a publication exist? > > Bob Devine

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 13:38:07 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272138.AA13450(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: East-Saskatchewan -> Saskatchewan [slightly revised patch] > > Here's a slightly revised patch for the East-Saskatchewan problem. The only > change to the previous patch is the last one -- the change to Mexico/General. > This version thus saves a bit of disk space, since Canada/Saskatchewan and > Mexico/General are identical. > > *** northamerica Thu Apr 23 10:34:33 1992 > --- northamerica.fix Tue Oct 27 13:32:04 1992 > *************** > *** 215,220 **** > --- 215,224 ---- > # be same as Pacific. Stick with rules posted in 1988 until more authoritative > # information is available. > > + # From W. Jones (October 27, 1992): > + # Since (I believe) around 1964, all of Saskatchewan is on CST year round, > + # by law [the U.S. Naval Observatory notwithstanding]. > + > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Canada 1969 max - Oct lastSun 2:00 0 S > Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D > *************** > *** 226,232 **** > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > --- 230,236 ---- > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/Saskatchewan -6:00 - CST > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > *************** > *** 290,296 **** > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > Zone Mexico/BajaNorte -8:00 Mexico P%sT > Zone Mexico/BajaSur -7:00 - MST > ! Zone Mexico/General -6:00 - CST > > ############################################################################### > > --- 294,300 ---- > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > Zone Mexico/BajaNorte -8:00 Mexico P%sT > Zone Mexico/BajaSur -7:00 - MST > ! Link Canada/Saskatchewan Mexico/General > > ###############################################################################

1 0

please remove US/Pacific-New [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

[My inclination would be to comment out the last two lines of the "pacificnew" file rather than making the changes indicated below, perhaps also adding a comment as to why they've been commented out. What do other folks feel? --ado] > Date: Tue, 27 Oct 92 13:09:45 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272109.AA11863(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: please remove US/Pacific-New > > The following patch removes US/Pacific-New, which causes more problems than it > cures (as I described in yesterday's message). Also, remove the file > `pacificnew'. > > *** Makefile Thu Jul 9 12:51:31 1992 > --- Makefile.fix Tue Oct 27 13:08:11 1992 > *************** > *** 189,195 **** > MANS= newctime.3 newtzset.3 tzfile.5 zic.8 zdump.8 > DOCS= Patchlevel.h README Theory $(MANS) date.1 Makefile > YDATA= africa antarctica asia australasia \ > ! europe northamerica southamerica pacificnew etcetera factory > NDATA= systemv > SDATA= solar87 solar88 solar89 > TDATA= $(YDATA) $(NDATA) $(SDATA) > --- 189,195 ---- > MANS= newctime.3 newtzset.3 tzfile.5 zic.8 zdump.8 > DOCS= Patchlevel.h README Theory $(MANS) date.1 Makefile > YDATA= africa antarctica asia australasia \ > ! europe northamerica southamerica etcetera factory > NDATA= systemv > SDATA= solar87 solar88 solar89 > TDATA= $(YDATA) $(NDATA) $(SDATA) >

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 13:04:32 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272104.AA11841(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: East-Saskatchewan -> Saskatchewan > > W. Jones <jones(a)skdad.usask.ca> writes that all of Saskatchewan is on CST year > round. I'll enclose his comments at the end of this message. So I propose > the following patch to the tz package: > > *** northamerica Thu Apr 23 10:34:33 1992 > --- northamerica.fix Tue Oct 27 12:58:38 1992 > *************** > *** 215,220 **** > --- 215,224 ---- > # be same as Pacific. Stick with rules posted in 1988 until more authoritative > # information is available. > > + # From W. Jones (October 27, 1992): > + # Since (I believe) around 1964, all of Saskatchewan is on CST year round, > + # by law [the U.S. Naval Observatory notwithstanding]. > + > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Canada 1969 max - Oct lastSun 2:00 0 S > Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D > *************** > *** 226,232 **** > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > --- 230,236 ---- > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/Saskatchewan -6:00 - CST > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > > > Here are Jones's comments: > > Date: Tue, 27 Oct 92 14:37:34 CST > From: jones(a)skdad.usask.ca (W. Jones) > To: eggert(a)twinsun.com > Cc: wright(a)sask.usask.ca > Organization: University of Saskatchewan, Saskatoon, Canada > > ... for this site, in order to follow local time correctly > requires choosing the ruleset named "East-Saskatchewan". Sounds > plausible, until you consider that the measure of places for which a > ruleset "Saskatchewan" or "West-Saskatchewan" applies is zero. > > How did this come about? Since (I believe) around 1964, all of > Saskatchewan is on CST year round, by law; but since that distinction > makes us rebels to North American convention, it tends to get left out of > discussions for simplicity. Thus when the timezone package appeared in > 1987, lo and behold we were lumped with the other Central places, as > implied in this table in the documentation: > > # From U. S. Naval Observatory (January 19, 1989): > # CANADA NEW FDL 3.5H BEHIND UTC ST.JOHN'S > # CANADA NEW FDL 1.5H BEHIND UTC APR 3 - OCT 29 > # CANADA ATLANTIC 4 H BEHIND UTC HALIFAX > # CANADA ATLANTIC 3 H BEHIND UTC APR 3 - OCT 29 > # CANADA EASTERN 5 H BEHIND UTC TORONTO, MONTREAL, OTTAWA > # CANADA EASTERN 4 H BEHIND UTC APR 3 - OCT 29 > # CANADA CENTRAL 6 H BEHIND UTC REGINA, WINNIPEG > # CANADA CENTRAL 5 H BEHIND UTC APR 3 - OCT 29 > # CANADA MOUNTAIN 7 H BEHIND UTC CALGARY, EDMONTON > # CANADA MOUNTAIN 6 H BEHIND UTC APR 3 - OCT 29 > # CANADA PACIFIC 8 H BEHIND UTC VANCOUVER > # CANADA PACIFIC 7 H BEHIND UTC APR 3 - OCT 29 > # CANADA YUKON SAME AS PACIFIC DAWSON > > I complained, and the eventual result was the adjustment below: > > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > # Bob Devine says that DST *is* observed in Newfoundland > Zone Canada/Newfoundland -3:30 Canada N%sT > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > > apparently the U.S. Naval Observatory was believed infallible, thus the > fellow from Saskatchewan must be following some kooky (and new) local > practice, thus we'll just throw him a sop....

1 0

US presidential election year politics help cause time zone bugs
by eggert＠twinsun.com Oct. 26, 1992

Oct. 26, 1992

Several people on the west coast of the US reported that their Unix systems failed to switch from daylight savings time to standard time yesterday, 26 October 1992. The reason? When they originally configured their systems, they were asked to choose one of the following time zone rules: US/Alaska US/Central US/Hawaii US/Pacific US/Aleutian US/East-Indiana US/Michigan US/Pacific-New US/Arizona US/Eastern US/Mountain US/Samoa ... Some people chose `US/Pacific-New' instead of `US/Pacific'. After all, who wants the old version when you can have the new version? Unfortunately, `US/Pacific-New' stands for ``Pacific Presidential Election Time'', which was passed by the House in April 1989 but never signed into law. In presidential election years, this rule would have delayed the PDT-to-PST switchover until after the election, to lessen the effect of broadcast news election projections on last-minute west-coast voters. Thus, US/Pacific-New and US/Pacific have always been identical -- until yesterday. This problem comes from combining Arthur David Olson's deservedly popular time zone software (which you can FTP from elsie.nci.nih.gov in pub/tz92b.tar.Z) with some overly terse vendor-supplied installation procedures. No doubt Olson did not use a more informative name like `US/Pacific-Presidential-Election' because of the 14-character file name length limit in many Unix file systems. In view of yesterday's experience, though, it seems unwise to make the hypothetical choice available under any name, since it gives free rein to Murphy's Law.

1 0

Re: strtotm
by guy＠auspex.com Sept. 16, 1992

Sept. 16, 1992

> strptime() [at least] falls into this category -- I believed Guy intended > it as the inverse of strptime() [or at least as close as you can get]. "Inverse of 'strftime()'". Yes, that was the basic idea. It does take a format parameter; however, it hasn't any magic way of figuring out whether 1/2/92 is January 2, 1992 or February 1, 1992 - you have to tell it how to interpret dates such as that, by passing it the right format string.

1 0

Re: strtotm
by Bradley White Sept. 16, 1992

Sept. 16, 1992

>> * Prior Art >> >> func who where >> ----------------------------------------------------- >> dparsetime() RAND/UCI MH >> getabsdate() Moraes C News >> getdate() USL Sys V Rel 4 >> getdate() Bellovin/Salz/Berets B News >> parsedate() Hamey/Accetta Mach >> partime() Harrenstien/Eggert RCS >> strptime() Harris SunOS 4.1[.x] > Are there any routines available that take a "format" parameter so that they > can scan dates that are in ambiguous formats. strptime() [at least] falls into this category -- I believed Guy intended it as the inverse of strptime() [or at least as close as you can get]. So, ... char * strptime(buf, fmt, tm) char *buf; char *fmt; struct tm *tm; strptime() converts the character string pointed to by buf to a time value, which is stored in the tm structure pointed to by tm, using the format specified by fmt. It is available under SunOS. > I would like to be able to scan dates in any of the following formats: > > M-D-Y T D-M-Y T There is no getting around that those D/M-numeric forms are just plain ambiguous. The best you can do is to use some ``internationalization'' feature like setlocale(LC_TIME, ...), or to just prefer one over the other. > I would like to be able to scan dates in any of the following formats: > > M-D-Y T D-M-Y T Y-M-D T > M/D/Y T D/M/Y T Y/M/D T > M D Y T D M Y T Y M D T > M.D.Y T D.M.Y T Y.M.D T Opinion: Any generalized date parser is overkill for these restricted situations. Brad

1 0

Re: strtotm
by Monty Solomon Sept. 16, 1992

Sept. 16, 1992

> Date: Mon, 22 Jun 92 22:42:18 -0400 (EDT) > From: Bradley White <bww+(a)CS.CMU.EDU> > > * Prior Art > > Perhaps a reasonable candidate already exists, or can be grown from > existing code. These routines (in alphabetical order) have been > mentioned: > > func who where > ----------------------------------------------------- > dparsetime() RAND/UCI MH > getabsdate() Moraes C News > getdate() USL Sys V Rel 4 > getdate() Bellovin/Salz/Berets B News > parsedate() Hamey/Accetta Mach > partime() Harrenstien/Eggert RCS > strptime() Harris SunOS 4.1[.x] Where are these various routines available? Are there any routines available that take a "format" parameter so that they can scan dates that are in ambiguous formats. I would like to be able to scan dates in any of the following formats: M-D-Y T D-M-Y T Y-M-D T M/D/Y T D/M/Y T Y/M/D T M D Y T D M Y T Y M D T M.D.Y T D.M.Y T Y.M.D T Where: M is the month expressed as 3, Mar, MAR, or March Y is the year expressed as 92 or 1992 T is optional and is the time (12- or 24-hour format) Thanks. Monty --- # Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405 # monty%roscom(a)think.com

1 0

problem with ltzset()
by Joel.Tornatore＠Eng.Sun.COM Sept. 9, 1992

Sept. 9, 1992

I am seeing a problem with _ltzset near daylight savings time when non-POSIX TZ values are used. Here is the output of a program that locates discontinuities in the time (seconds since epoch are increased by 3600; check if hour increased by one): gap % tzcheck TZ=PST8PDT 720005582: 9/25/92 1:33 733919582: 3/4/93 3:33 752059982: 9/31/93 1:33 ^C gap % setenv TZ US/Pacific gap % tzcheck TZ=US/Pacific 720034366: 9/25/92 9:32 733948366: 3/4/93 11:32 752088766: 9/31/93 9:32 It's off by the GMT offset, 8 hours, in every case. If EST5EDT and US/Easter are used, it's off by 5 hours. Has anyone seen or fixed this problem? This is on SVR4. joel tornatore jrt(a)eng.sun.com

2 1

test
by Glenn.Wright＠UK.Sun.COM Sept. 9, 1992

Sept. 9, 1992

please ignore.

1 0

Re: strtotm
by ado July 7, 1992

July 7, 1992

Two general questions about the high-test end of the string-to-time function spectrum: 1. What's the right way to handle the duration of events (such as "Lent" or "high tea")? 2. What calendar-keeping software out in the field--be it UNIX-, DOS-, Mac-, or whatever-else-based, can be used to get an idea of the capabilities that might be useful in a high-test function? --ado

2 1

Re: functions to convert ASCII time
by abe＠mace.cc.purdue.edu June 23, 1992

June 23, 1992

Brad, I've been reading this discussion with interest, because I had to create a function some time ago to convert mail header date/time strings to time_t values. While my function represents another possible entry in your list, I don't think it answers all the criteria that this discussion has established. For example, it returns a time_t, not a struct tm, and it doesn't return a character pointer to the end ot its scan (although it could). The major contribution of this function might be the list of time zone abbreviations that it understands. Paul Eggert has helped me assemble (and purify) it. :-) I will be glad to contribute my atotm() function to the list of prior art, for whatever value it might have. Vic Abell

1 0

1st of 2 forwarded messages from Bradley White: time2posix/posix2time
by ado June 23, 1992

June 23, 1992

The attached comes from Bradley White, bww+(a)cs.cmu.edu. Your comments will be appreciated! --ado I have found [time2posix() and posix2time()] invaluable when dealing with things like external time formats, or programs that want to wake up every minute (as opposed to every 60 seconds), on systems that allow for leap seconds.... /* ** IEEE Std 1003.1-1988 (POSIX) legislates that 536457599 ** shall correspond to "Wed Dec 31 23:59:59 GMT 1986", which ** is not the case if we are accounting for leap seconds. ** So, we provide the following conversion routines for use ** when exchanging timestamps with POSIX conforming systems. */ static long leapcorr(timep) time_t * timep; { register struct state * sp; register struct lsinfo * lp; register int i; if (!lcl_is_set) (void) tzset(); sp = lclptr; i = sp->leapcnt; while (--i >= 0) { lp = &sp->lsis[i]; if (*timep >= lp->ls_trans) return lp->ls_corr; } return 0L; } time_t time2posix(t) time_t t; { return t - leapcorr(&t); } time_t posix2time(t) time_t t; { time_t x, y; /* ** For a positive leap second hit, the result ** is not unique. For a negative leap second ** hit, the corresponding time doesn't exist, ** so we return an adjacent second. */ x = t + leapcorr(&t); y = x - leapcorr(&x); if (y < t) { do { x++; y = x - leapcorr(&x); } while (y < t); if (t != y) return x-1; } else if (y > t) { do { --x; y = x - leapcorr(&x); } while (y > t); if (t != y) return x+1; } return x; }

2 1

2nd of 2 forwarded messages from Bradley White: strtotm
by ado June 23, 1992

June 23, 1992

The attached comes from Bradley White, bww+(a)cs.cmu.edu. Your comments will be appreciated! --ado I often miss an at-least-pseudo-standard means of converting a reasonable string date/time specification into a "struct tm", and, from the number of requests on different newsgroups, it appears others do too. Perhaps adding one to the "tz" package might be a reasonable thing to do? If you concur, and are open to suggestions or want to open it up for discussion, here are some random thoughts on the interface off the top of my head. It's undoubtedly deficient. Then again, perhaps you have considered all of this before, and decided against it? Brad ---------->8---------- static int _strtotm(str, flags, np, tp) char *str; unsigned *flags; struct tm *np; struct tm *tp; { /* * decode str into tp using (if necessary) flags and np; * undoubtedly requires yacc and/or lex to do a good job * * return 0 on success, non-zero (error codes?) on error * * The only flags I can currently think of are: * IN: * XX_DEFPAST default to most recent past * matching time, rather than * most near future matching time, * for incomplete specifications * XX_DEFDDMM DD/MM/YY instead of MM/DD/YY * if ambiguous * XX_DEFYYMM YY/MM/DD instead of above * if ambiguous * OUT: * XX_DEFTIME no time specified, used "now" time * XX_DEFZONE no zone specified, used "now" zone */ return XX_EUNIMPL; } struct tm * strtotm(str, flags, np, tp) char *str; unsigned *flags; struct tm *np; /* "now" for relative times */ struct tm *tp; /* space for result, malloc if NULL */ { struct tm nowtm, tmptm; if (np == 0) { time_t now = time((time_t *) 0); np = localtime(&now); } nowtm = *np; if (_strtotm(str, flags, &nowtm, &tmptm) != 0) return 0; #if 0 /* * I'd like to do this to check/canonicalize the struct tm, * but it is really only appropriate if `tmptm' is in the * local timezone, right??? Perhaps timeoff()??? */ if (mktime(&tmptm) == -1) return 0; #endif if (tp == 0 && (tp = malloc(sizeof *tp)) == 0) return 0; *tp = tmptm; return tp; }

2 1

Re: 2nd of 2 forwarded messages from Bradley White: strtotm
by guy＠auspex.com June 18, 1992

June 18, 1992

> I often miss an at-least-pseudo-standard means of converting a > reasonable string date/time specification into a "struct tm", and, > from the number of requests on different newsgroups, it appears > others do too. Perhaps adding one to the "tz" package might be > a reasonable thing to do? My first attempt at coming up with such a routine was "strptime()", in SunOS 4.1[.x]. It's somewhat of a "strftime()" inverse; it takes a format string and a date/time string, and fills in a "struct tm". Good things about it: it returns a pointer one past the last character processed, so you can continue sucking other stuff out of the string. fairly easy to internationalize, *if* your locale-support system lets you ask for various date formats for the current locale (SunOS 4.1[.x]'s does; not all others do). Bad things about it: the way it supports "optional" fields - e.g., leaving the seconds or minutes out and getting 0, or leaving the year out and getting this year, is a gross hack - "strptime()" "knows" that those fields are optional. Steve Bellovin came up with a rather powerful function, "getdate()", which appears in the B news source, among other places. It has a YACC grammar to parse the string, and can handle all sorts of special strings, such as "tomorrow", "now", "next week", etc.. It takes a pointer to the string to be scanned, and a pointer to a "struct timeb" containing the current time, as arguments, and returns a "time_t". Good things about it: takes a *very* large number of different specifications and turns them into dates. Bad things about it: it's hard to "internationalize", because the grammar is hardcoded, as are the actions for different reductions; the best way to internationalize it would probably be to hand-code different versions for different locales, and have the common "getdate()" routine load up the appropriate version, based on the setting of the LANG environment variable, at run time. Not all systems have run-time dynamic loading as a standard feature. it should really split the "string to 'struct tm'" and "'struct tm' to 'time_t'" functions up - i.e., just make it convert a string to a "struct tm", and let "mktime()" to the rest. it doesn't return a pointer one past the last character processed. System V Release 4 also has a routine named "getdate()", but it's different. It takes a string as an argument, and returns a pointer to a "struct tm". It works by getting a list of "strftime()"-style date formats from a file, and scanning the string against each of them; if it finds one that matches, it returns a "struct tm" based on that match. Good things about it: it can deal with optional fields, and doesn't have "strptime()"s gross hack to do it; you just have multiple formats, some with the optional fields, and some without. Bad things about it: it's not clear it responds to the setting of LANG, so localization isn't as good as it could be. it doesn't return a pointer one past the last character processed. My personal preferences are, in order: a Bellovin-style "getdate()", with the modifications I suggest; if all systems had run-time dynamic loading, I think that'd be ideal. an SVR4-style "getdate()", with the list of strings selected by the setting of LANG.

1 0

bug in ctime() for bogus values of TZ [from dupuy@cs.columbia.edu]
by ado April 28, 1992

April 28, 1992

The attached is redistributed with permission of the original author. --ado ... From: dupuy(a)hudson.cs.columbia.edu (Alexander Dupuy) Message-Id: <9204280549.AA22287(a)hudson.cs.columbia.edu> To: ado(a)ncifcrf.gov, sunbugs(a)sun.com Subject: bug in ctime() for bogus values of TZ (SPARC/SunOS 4.1.1) Reply-To: dupuy(a)cs.columbia.edu Status: RO As noted in the script and output below, the output of ctime() is incorrect when the TZ environment variable is set to a string which contains a "-" or "+" but which is not present in the the zoneinfo database. It appears that the numeric value of the string following the "+" or "-" (0 if non-numeric) is treated as an offset from UTC, and either the first three characters of TZ or the string preceding the "+" or "-", (whichever is longer) is used as the zone letters. This behavior occurs regardless of the string preceding the "+" or "-", although using "GMT" provides the most convincing bogus timestamp. As a result, it is trivially easy to generate bogus time strings up to 24 hours in the past or future, using "TZ=GMT+24" or "TZ=GMT-24". While one might attempt to call it a feature to allow arbitrary offsets to be specified by the TZ environment variable (is this for compatibility with an old System V feature?) at the very least the zone letters should include the entire TZ environment variable so that spoofing isn't possible. However, the offset is computed in the opposite sense of the offset computed in the "GMT+/-XX" timezones present in the zoneinfo database. For this reason, and because it's quite easy to add timezones to the database, I would strongly argue that this is not in any way a useful feature, and that the correct behavior when presented with an invalid timezone is to use GMT with no offset, and indicate it as GMT. Note also that "GMT+14" is not present in the database, even though the USNO tables indicate that East Siberia (Uelen) was 14 hours ahead of GMT in the summer. I think this may no longer be the case, as I believe most timezones were shifted back (both summer and winter) when Russia declared independence. Still, it is at least a valid historical timezone name... ... @alex _______________________________________________________________________________ $ cat tzfun #!/bin/sh echo -n "GMT : " TZ=GMT date echo "" offsets="11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26" for o in $offsets do echo -n "GMT+$o : " TZ=GMT+$o date done echo "" for o in $offsets do echo -n "FOO-$o : " TZ=FOO-$o date done # $ ./tzfun GMT : Tue Apr 28 03:52:57 GMT 1992 GMT+11 : Tue Apr 28 14:52:57 GMT+1100 1992 GMT+12 : Tue Apr 28 15:52:58 GMT+1200 1992 GMT+13 : Tue Apr 28 16:52:58 GMT+1300 1992 GMT+14 : Mon Apr 27 13:52:58 GMT 1992 GMT+15 : Mon Apr 27 12:52:58 GMT 1992 GMT+16 : Mon Apr 27 11:52:58 GMT 1992 GMT+17 : Mon Apr 27 10:52:58 GMT 1992 GMT+18 : Mon Apr 27 09:52:58 GMT 1992 GMT+19 : Mon Apr 27 08:52:58 GMT 1992 GMT+20 : Mon Apr 27 07:52:59 GMT 1992 GMT+21 : Mon Apr 27 06:52:59 GMT 1992 GMT+22 : Mon Apr 27 05:52:59 GMT 1992 GMT+23 : Mon Apr 27 04:52:59 GMT 1992 GMT+24 : Mon Apr 27 03:52:59 GMT 1992 GMT+25 : Tue Apr 28 03:52:59 GMT 1992 GMT+26 : Tue Apr 28 03:52:59 GMT 1992 FOO-13 : Tue Apr 28 13:53:02 FOO 1992 FOO-11 : Tue Apr 28 14:53:02 FOO 1992 FOO-12 : Tue Apr 28 15:53:02 FOO 1992 FOO-13 : Tue Apr 28 16:53:02 FOO 1992 FOO-14 : Tue Apr 28 17:53:02 FOO 1992 FOO-15 : Tue Apr 28 18:53:02 FOO 1992 FOO-16 : Tue Apr 28 19:53:02 FOO 1992 FOO-17 : Tue Apr 28 20:53:02 FOO 1992 FOO-18 : Tue Apr 28 21:53:02 FOO 1992 FOO-19 : Tue Apr 28 22:53:02 FOO 1992 FOO-20 : Tue Apr 28 23:53:03 FOO 1992 FOO-21 : Wed Apr 29 00:53:03 FOO 1992 FOO-22 : Wed Apr 29 01:53:03 FOO 1992 FOO-23 : Wed Apr 29 02:53:03 FOO 1992 FOO-24 : Wed Apr 29 03:53:03 FOO 1992 FOO-25 : Tue Apr 28 03:53:03 FOO 1992 FOO-26 : Tue Apr 28 03:53:03 FOO 1992

1 0