- tz - lists.iana.org

forwarded message from Andy J. Chichak
by Garrett Wollman April 28, 1994

April 28, 1994

------- start of forwarded message (RFC 934) ------- Message-Id: <199404280314.LAA01792(a)gateway.tiasur.tomsk.su> X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 805 Precedence: bulk From: "Andy J. Chichak" <chch(a)gateway.tiasur.tomsk.su> Sender: freebsd-tz-owner(a)freefall.cdrom.com To: freebsd-tz(a)freefall.cdrom.com (FreeBSD time zone) Subject: some questions about src/share/zoneinfo/datfiles/europe Date: Thu, 28 Apr 1994 11:14:24 +0800 (TSD) Hello ! I`ve tried to setup my time & found some interest things : Always our timezone was TSK (TSD), TSK is in Tashkent ... We have 4 hours difference in time with Moscow & 1 hour with Irkutsk => time in Irkutsk - time in Moscow = 5 , but in 'europe' it is so : # 3:00 MSK MSD Moscow # 3:00 TUR+DST Turkey (no longer used)* # 4:00 SSK SSD Sverdlovsk* # 5:00 OSK OSD Omsk* # 6:00 NSK NSD Novosibirsk # 7:00 ISK ISD Irkutsk* >? 7:00 TSK TSD Tomsk >? 8:00 ISK ISD Irkutsk And one more problem : Zone Asia/Omsk 4:53:36 - LMT 1924 May 2 5:00 - TSK 1957 Mar 6:00 Russia TS%s 1991 Sep 29 3:00 > ^^^^ ??????? 5:00 Russia OS%s I`ll try to know all about time zones in Russia. Who is 'europe' coordinator ? /Andy ------- end -------

1 0

Re: Australian daylight savings time [forwarded with permission]
by Bradley White April 11, 1994

April 11, 1994

John Connolly <connolly(a)zk3.dec.com> writes: > I am tracking down a problem reported by a customer. He indicates that the > zoneinfo for South Australia is off by one week. > > I have no idea if he is correct or not but I assume he is if he lives there. > Is there there a way to check this officially and if it is wrong I would > like to see the change made in the right places. The file contains the > following rule: > > Rule AS 1990 max even Mar Sun>=22 3:00 0 - > > He has suggested the rule be changed to: > > Rule AS 1990 max even Mar Sun>=15 3:00 0 - > > Any help on this would be greatly appreciated. ado, Here are five old messages chronicling the Adelaide Festival rule. If Sun, 15 March, 1992 was at +1030 as kre asserts, but yet Sun, 20 March, 1994 was at +0930 as John Connolly's customer seems to assert, then I can only conclude that the actual rule is more complicated than either of those given above. kre's ``2nd last Sunday'' is consistent with those dates, but perhaps his ``the Sunday we pick for this year'' is the real truth. bww ------- Begin Forwarded Message #1 Date: Wed, 11 Mar 92 12:21:42 -0500 (EST) From: Bradley White <bww+(a)CS.CMU.EDU> Subject: Re: australasia To: Arthur David Olson <ado(a)ELSIE.NCI.NIH.GOV> Cc: Zone Watchers <tz(a)ELSIE.NCI.NIH.GOV> I believe ... Rule AS 1991 max - Mar Sun>=1 3:00 0 - ... to be wrong. Recent correspondence with a friend in Adelaide contained the following exchange: Due to the Adelaide Festival, South Australia delays setting back our clocks for a few weeks. ------- End Forwarded Message ------- Begin Forwarded Message #2 Date: Fri, 13 Mar 92 07:49:50 +1000 From: Robert Elz <kre(a)munnari.oz.au> Subject: Re: australasia To: Bradley White <bww+(a)CS.CMU.EDU> Cc: Arthur David Olson <ado(a)ELSIE.nci.nih.gov> I heard that apparently (or at least, it appears that) South Aus will have an extra 3 weeks daylight saving every even numbered year (from 1990). That's when the Adelaide Festival is on... ------- End Forwarded Message ------- Begin Forwarded Message #3 Date: Sat, 14 Mar 92 13:27:30 EST From: ado(a)elsie.nci.nih.gov (Arthur David Olson) Subject: South Australia DST cutoff day To: bww+(a)cs.cmu.edu, kre(a)munnari.oz.au An extra three weeks would make the ending test "Sun>=22" as opposed to the "Sun>=1" used everywhere else, right? Making what we need Rule AS 1986 max adfest Mar Sun>=22 3:00 0 - Rule AS 1986 max nonfest Mar Sun>=1 3:00 0 - plus a "yearistype" script? ------- End Forwarded Message ------- Begin Forwarded Message #4 Date: Sat, 14 Mar 92 20:11:44 -0500 (EST) From: Bradley White <bww+(a)CS.CMU.EDU> Subject: Re: South Australia DST cutoff day To: Arthur David Olson <ado(a)elsie.nci.nih.gov> Cc: Robert Elz <kre(a)MUNNARI.OZ.AU> I don't know the exact rules in this case, but historically things usually happen on the ``third Sunday,'' which would be "Sun>=15" or "Sun<=21". Given that it is "Sun, 15 Mar 92" in South Australia at this very moment, it should be easy to find out if the shift was today, or is next week. [Aside: I actually just received a message from someone in Adelaide and the timezone still read +1030 (daylight time), so perhaps the ">=22" is right.] ------- End Forwarded Message ------- Begin Forwarded Message #5 Date: Mon, 16 Mar 92 00:57:07 +1000 From: Robert Elz <kre(a)munnari.oz.au> Subject: Re: South Australia DST cutoff day To: Bradley White <bww+(a)CS.CMU.EDU> Cc: Arthur David Olson <ado(a)elsie.nci.nih.gov> DST didn't end in Adelaide today (yesterday) (Aside: it did in NZ for a cross check on what the rules for NZ say). That's for sure - there was a world cup cricket match in Adelaide yesterday (Sunday), and it was certainly still daylight saving there. Quite apart from that, the news reports said "an extra 3 weeks in SA" and yesterday was just 2 weeks, so there's certainly one to go. But whether its "4th Sunday" or "2nd last Sunday" I have no idea whatever... (its just as likely to be "the Sunday we pick for this year"...) ------- End Forwarded Message

1 0

Australian daylight savings time [forwarded with permission]
by ado April 11, 1994

April 11, 1994

> From connolly(a)zk3.dec.com Fri Apr 8 14:35:03 1994 > Return-Path: <connolly(a)zk3.dec.com> > Received: from decvax.dec.com (decvax.zk3.dec.com) by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA16343; Fri, 8 Apr 94 14:35:01 EDT > Received: from quarry.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) > id AA00453; Fri, 8 Apr 1994 14:34:58 -0400 > Received: from localhost by quarry.zk3.dec.com; (5.65/1.1.8.2/07Apr94-0144PM) > id AA06464; Fri, 8 Apr 1994 14:34:56 -0400 > Message-Id: <9404081834.AA06464(a)quarry.zk3.dec.com> > To: ado(a)elsie.nci.nih.gov > Cc: connolly(a)quarry.zk3.dec.com > Subject: Australian daylight savings time > Date: Fri, 08 Apr 94 14:34:56 -0400 > From: connolly(a)zk3.dec.com > X-Mts: smtp > Status: RO > > Arthur, > > I am tracking down a problem reported by a customer. He indicates that the > zoneinfo for South Australia is off by one week. > > I have no idea if he is correct or not but I assume he is if he lives there. Is there there a way to check this officially > and if it is wrong I would like to see the change made in the right places. The > file contains the following rule: > > Rule AS 1990 max even Mar Sun>=22 3:00 0 - > > He has suggested the rule be changed to: > > Rule AS 1990 max even Mar Sun>=15 3:00 0 - > > Any help on this would be greatly appreciated. > > John Connolly

1 0

Re: problems with tz-1994e `date'+mktime and Solaris 2.3 strftime
by eggert＠twinsun.com April 8, 1994

April 8, 1994

I think I've figured out the problem with tz-1994e under Solaris 2.3. Guy Harris's intuition was right -- it was the leading-`_' symbols. The problem is that tz-1994e's `date' command calls Sun's strftime, which invokes mktime to set _tzname (not tzname, since a non-Posix Standard C program might have its own external variable called tzname, so the Sun tzname is a weak reference to _tzname). But the tz package defines its own mktime, which sets tzname (which is qnot _tzname). Sun's mktime never gets invoked and therefore Sun's _tzname never gets initialized. I think that this bug will happen in any SVR4 system, regardless of whether -DUSG_COMPAT and -DTM_GMTOFF. The only fix that I can see for tz is the one I already submitted, namely to use tz's strftime instead of the one supplied with the system, as follows: =================================================================== RCS file: Makefile,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c -r1994.5.1.1 -r1994.5.1.2 *** Makefile 1994/04/03 02:54:41 1994.5.1.1 --- Makefile 1994/04/03 19:47:59 1994.5.1.2 *************** *** 280,292 **** if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's logwtmp and strftime in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a logwtmp.o strftime.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o $@ rm -f ,lib.a --- 280,292 ---- if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's getopt and logwtmp in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a getopt.o logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o $@ rm -f ,lib.a

1 0

Re: linking problems with tz-1994e `date' on Solaris 2.3
by Joel.Tornatore＠Eng.Sun.COM April 7, 1994

April 7, 1994

> > 1. The Solaris 2.3 strftime gets confused about the timezone when > > it's linked together with `date'. I don't have the Solaris 2.3 > > source, so I don't know the details, but my guess is that Solaris 2.3 > > strftime assumes that tzset sets some global variables in the Solaris > > 2.3 library, but since we've substituted our own tzset this assumption > > no longer applies. The symptoms are that `date' prints the correct > > time but with either "GMT" or "" substituted for the time zone name. > > As I remember, in SV-derived systems, "tzset()" will set the "timezone", > "daylight", and "tzname" variables; in systems derived from more recent > SV's (SVR3.1 and later, I think), it also sets "altzone". > > SunOS 5.3 is SVR4-derived, so any time zone code installed on it should > arrange to set "timezone", "altzone", "daylight", and "tzname" when > "tzset()" is called. (It may, I think, reset them if there aren't > single values for them that make sense - e.g., if there are different > time zone abbreviations for standard time at different dates, or > different time zone abbreviations for summer time at different dates, I > think "localtime()" may change the setting of "tzname". That, at least, > was the intent.) > > It may be that "strftime()" is expecting "tzname" to be set; if it's not > being set, that may be the source of the problem. The SunOS 5.3 version of tzset() does set these variables: timezone daylight tzname altzone and it does reset them if TZ is not set properly. localtime() calls tzset(), so it will change the tzname[] values. joel

3 4

linking problems with tz-1994e `date' on Solaris 2.3
by eggert＠lotl.twinsun.com April 4, 1994

April 4, 1994

I had two problems linking tz-1994e `date' under Solaris 2.3. 1. The Solaris 2.3 strftime gets confused about the timezone when it's linked together with `date'. I don't have the Solaris 2.3 source, so I don't know the details, but my guess is that Solaris 2.3 strftime assumes that tzset sets some global variables in the Solaris 2.3 library, but since we've substituted our own tzset this assumption no longer applies. The symptoms are that `date' prints the correct time but with either "GMT" or "" substituted for the time zone name. The workaround is to use tz's strftime instead. 2. The system `getopt' and tz `getopt' clash as follows. In Solaris 2.3, `getopt' is broken into two object modules to make its more efficient in a shared library. One, `opt_data.o', merely contains the modifiable data (optind, optarg, opterr, and optopt). (The other, getopt.o, contains the code.) opt_data.o contains definitions for all four symbols, whereas tz's getopt contains two definitions (opterr and optind) and two common symbols (optopt and optarg). This confuses the Solaris 2.3 linker: it brings in opt_data to resolve the common symbols, but then it complains that opterr and optind are multiply defined. Here are the symptoms: gcc -static -Dlint -g -O -Wall -DTZDIR=\"etc/zoneinfo\" date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o date ld: fatal: symbol `optind' is multiply defined: (file getopt.o and file /usr/lib/libc.a(opt_data.o)); ld: fatal: symbol `opterr' is multiply defined: (file getopt.o and file /usr/lib/libc.a(opt_data.o)); ld: fatal: File processing errors. No output written to date *** Error code 1 One patch might be to modify tz's getopt.c to statically initialize optopt and optarg to 0 (I haven't tested this). Another patch, which I've taken below, is to use the system getopt if it is available. Here is a patch that embodies the above two suggestions. =================================================================== RCS file: Makefile,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c -r1994.5.1.1 -r1994.5.1.2 *** Makefile 1994/04/03 02:54:41 1994.5.1.1 --- Makefile 1994/04/03 19:47:59 1994.5.1.2 *************** *** 280,292 **** if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's logwtmp and strftime in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a logwtmp.o strftime.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o $@ rm -f ,lib.a --- 280,292 ---- if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's getopt and logwtmp in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a getopt.o logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o $@ rm -f ,lib.a

2 1

mktime bugs around the edges
by eggert＠lotl.twinsun.com April 3, 1994

April 3, 1994

Here are some mktime bugs in tz-1994e. (Bugs that PCTS should have caught :-) mktime fails on the earliest representable time (Fri Dec 13 20:45:52 1901 GMT). mktime does not fail, as it should, with one plus the last representable time (i.e. with Tue Jan 19 03:14:08 2038 GMT). It wraps around and reports Fri Dec 13 20:45:52 1901 GMT instead. When normalizing times, mktime assumes that every minute contains 60 seconds. This is incorrect if leap seconds are in use. mktime does not detect arithmetic overflow when normalizing nonsensically large inputs. Here is a patch. =================================================================== RCS file: localtime.c,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c2 -r1994.5.1.1 -r1994.5.1.2 *** localtime.c 1994/04/03 02:54:41 1994.5.1.1 --- localtime.c 1994/04/03 21:25:32 1994.5.1.2 *************** *** 114,118 **** static void localsub P((const time_t * timep, long offset, struct tm * tmp)); ! static void normalize P((int * tensptr, int * unitsptr, int base)); static void settzname P((void)); static time_t time1 P((struct tm * tmp, --- 114,120 ---- static void localsub P((const time_t * timep, long offset, struct tm * tmp)); ! static int increment_overflow P((int * number, int delta)); ! static int normalize_overflow P((int * tensptr, int * unitsptr, ! int base)); static void settzname P((void)); static time_t time1 P((struct tm * tmp, *************** *** 1155,1160 **** */ ! static void ! normalize(tensptr, unitsptr, base) int * const tensptr; int * const unitsptr; --- 1157,1172 ---- */ ! static int ! increment_overflow(number, delta) ! int * number; ! int delta; ! { ! int number0 = *number; ! *number = number0 + delta; ! return (*number < number0) != (delta < 0); ! } ! ! static int ! normalize_overflow(tensptr, unitsptr, base) int * const tensptr; int * const unitsptr; *************** *** 1166,1171 **** (*unitsptr / base) : (-1 - (-1 - *unitsptr) / base); - *tensptr += tensdelta; *unitsptr -= tensdelta * base; } --- 1178,1183 ---- (*unitsptr / base) : (-1 - (-1 - *unitsptr) / base); *unitsptr -= tensdelta * base; + return increment_overflow(tensptr, tensdelta); } *************** *** 1204,1225 **** *okayp = FALSE; yourtm = *tmp; ! if (yourtm.tm_sec >= SECSPERMIN + 2 || yourtm.tm_sec < 0) ! normalize(&yourtm.tm_min, &yourtm.tm_sec, SECSPERMIN); ! normalize(&yourtm.tm_hour, &yourtm.tm_min, MINSPERHOUR); ! normalize(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY); ! normalize(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR); while (yourtm.tm_mday <= 0) { ! --yourtm.tm_year; ! yourtm.tm_mday += ! year_lengths[isleap(yourtm.tm_year + TM_YEAR_BASE)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! yourtm.tm_mday -= ! year_lengths[isleap(yourtm.tm_year + TM_YEAR_BASE)]; ! ++yourtm.tm_year; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year + ! TM_YEAR_BASE)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; --- 1216,1236 ---- *okayp = FALSE; yourtm = *tmp; ! if ( normalize_overflow(&yourtm.tm_hour, &yourtm.tm_min, MINSPERHOUR) ! || normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY) ! || normalize_overflow(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR) ! || increment_overflow(&yourtm.tm_year, TM_YEAR_BASE)) ! return WRONG; while (yourtm.tm_mday <= 0) { ! if (increment_overflow(&yourtm.tm_year, -1)) ! return WRONG; ! yourtm.tm_mday += year_lengths[isleap(yourtm.tm_year)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! yourtm.tm_mday -= year_lengths[isleap(yourtm.tm_year)]; ! if (increment_overflow(&yourtm.tm_year, 1)) ! return WRONG; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; *************** *** 1227,1235 **** if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! ++yourtm.tm_year; } } ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = 0; /* ** Calculate the number of magnitude bits in a time_t --- 1238,1264 ---- if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! if (increment_overflow(&yourtm.tm_year, 1)) ! return WRONG; } } ! if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) ! return WRONG; ! if (yourtm.tm_year < EPOCH_YEAR - TM_YEAR_BASE) { ! /* ! ** We can't set tm_sec to 0, because that might push the ! ** time below the minimum representable time. ! ** Set tm_sec to 59 instead. ! ** This assumes that the minimum representable time is ! ** not in the same minute that a leap second was deleted from, ! ** which is a safer assumption than using 58 would be. ! */ ! if (increment_overflow(&yourtm.tm_sec, 1 - SECSPERMIN)) ! return WRONG; ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = SECSPERMIN - 1; ! } else { ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = 0; ! } /* ** Calculate the number of magnitude bits in a time_t *************** *** 1298,1302 **** } label: ! t += saved_seconds; (*funcp)(&t, offset, tmp); *okayp = TRUE; --- 1327,1334 ---- } label: ! newt = t + saved_seconds; ! if ((newt < t) != (saved_seconds < 0)) ! return WRONG; ! t = newt; (*funcp)(&t, offset, tmp); *okayp = TRUE;

1 0

Re: mktime() failures under PCTS testing
by eggert＠twinsun.com April 1, 1994

April 1, 1994

Mark Brader, who I believe is well connected with the C standardization process, wrote a news article about the mktime problem in which he indicated that he thought that mktime could yield -1 in the spring-forward gap (i.e. that this particular PCTS case is incorrect). I'll enclose a copy of the article at the end of this message. (It responds to another article that I don't have a copy of.) This is probably the best we can do until I get an official response to the C Standard defect report that I filed earlier this week. ----- Newsgroups: comp.std.c From: msb(a)sq.sq.com (Mark Brader) Subject: Re: Can mktime return -1 for times in the spring-forward gap? Message-ID: <1994Mar25.173447.2810(a)sq.sq.com> Summary: Yes, it's undefined behavior Organization: SoftQuad Inc., Toronto, Canada References: <Cn4tnp.DvM(a)twinsun.com> <2mr48c$duk(a)usenet.pa.dec.com> Date: Fri, 25 Mar 94 17:34:47 GMT The original question was about mktime() with the tm_isdst member negative, and times in the "spring-forward gap", i.e. the transition to Daylight Saving Time. > I think the standard contradicts itself. The relevant fields are not > restricted to the usual ranges, yet if the calendar time cannot be > represented then mktime returns -1. I think that your example requires > a return of -1, and an example with tm_hour being 27 is a calendar time > that cannot be represented so it requires a return of -1, even though > mktime has to force the fields into the usual ranges. I think that this is a strained interpretation, and that if a ruling was requested, the response would be that the standard is clear enough as it is. The intent of saying that "the original values ... are not restricted to the ranges indicated above" obviously was to allow alternative specifications for a calendar time, so that 27:00 UTC on October 15, 1982, would signify the same as 03:00 UTC on October 16, 1982; and I don't think there is any other reasonable way to read the actual text. > > The Rationale (section 4.12.2.3) clearly allows mktime to yield -1 in the > > ``fall-backward fold'' [i.e. the opposite transition]... > > The rationale conflicts with the standard, and the standard has priority. > If the tm_isdst field is -1, then a time in the "fall-backward fold" is a > calendar time that can be represented in two ways, so it can be represented, > so the return value cannot be -1 ... The Rationale for 4.12.2.3 does not specify what kind of behavior is involved here, but seems to mean that it is unspecified; perhaps that is what was intended. On reading 4.12.2.3/7.12.2.3 in the actual standard, though, I think the behavior is undefined. What it specifies is only that the broken-down time is converted to a calendar time value. For times in the gap and the fold, no well-defined conversion exists. Therefore, as I see it, the general exclusions in 1.6/3.16 and/or 4.1.6/7.1.7 apply, and the behavior is undefined. (And I think that's an unwise choice; I'd rather that it either be unspecified, or implementation-defined, or that -1 be returned.) > Perhaps now is the calendar time for a few more defect reports. Chuckle. I'd say so. > Every technical corrigendum is met by an equally troublesome new defect > report. But then again... -- Mark Brader, msb(a)sq.com | "You keep using that word. I do not think it means SoftQuad Inc., Toronto | what you think it means." -- The Princess Bride This article is in the public domain.

1 0

Re: 18 sec
by Mills＠udel.edu March 31, 1994

March 31, 1994

Garrett, Wrong. See rfc1589 for an explanation. Dave

1 0

tzcode94e.tar.gz
by ado March 31, 1994

March 31, 1994

The file "tzcode94e.tar.gz" is now available for anonymous ftp from the "~ftp/pub" directory of elsie.nci.nih.gov (128.231.16.1); "tzdata94d.tar.gz" remains the latest data file. The new code incorporates a change for the benefit of PCTS; diffs are attached. --ado SCCS/s.Makefile: 7.21 vs. 7.23 *** 7.21/Makefile Wed Mar 30 23:32:14 1994 --- 7.23/Makefile Wed Mar 30 23:32:15 1994 *************** *** 1,4 **** ! # @(#)Makefile 7.21 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.23 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 168,173 **** --- 168,179 ---- # -DCMUCS # to the end of the "CFLAGS=" line # This function is not described in X3J11's work. + # + # NIST-PCTS:151-2, Version 1.4, (1993-12-03) is a test suite put + # out by the National Institute of Standards and Technology + # which claims to test C and Posix conformance. If you want to pass PCTS, add + # -DPCTS + # to the end of the "CFLAGS=" line. CFLAGS= SCCS/s.localtime.c: 7.17 vs. 7.18 *** 7.17/localtime.c Wed Mar 30 23:32:17 1994 --- 7.18/localtime.c Wed Mar 30 23:32:18 1994 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.17"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.18"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1308,1315 **** --- 1308,1326 ---- if (tmp->tm_isdst > 1) tmp->tm_isdst = 1; t = time2(tmp, funcp, offset, &okay); + #ifdef PCTS + /* + ** PCTS code courtesy Grant Sullivan (grant(a)osf.org) + */ + if (okay) + return t; + if (tmp->tm_isdst < 0) + tmp->tm_isdst = 0; /* reset to std and try again */ + #endif /* defined PCTS */ + #ifndef PCTS if (okay || tmp->tm_isdst < 0) return t; + #endif /* !defined PCTS */ /* ** We're supposed to assume that somebody took a time of one type ** and did some math on it that yielded a "struct tm" that's bad.

1 0

18 sec
by Garrett Wollman March 29, 1994

March 29, 1994

<<On Tue, 29 Mar 1994 10:12:19 +0200 (MESZ), Hinrich Eilts <eilts(a)late.e-technik.uni-erlangen.de> said: > I synchronized FreeBSD-1.1-BETA to a stratum-1 timeserver by ntpdate > and xntpd and compared localtime by "date" with it and two other > machines, which are synchronized by xntpd too. FreeBSD has a > difference of -18 secounds to all other machines (a NeXT-Station > with NeXTStep, a Sun with SunOS 4.x and a HP9000-750 with > HPUX). What you are seeing is the interaction of several different `features' of NTP and FreeBSD. I'll try to explain, and again hope that somebody out there can provide a complete solution. Here are the problems... 1) The timezone database does not reflect the fact that the first time step, in going from GMT (pre-1972) to UTC (1972 to present) was actually 10 seconds, and not just one like all subsequent leap seconds. 2) The timezone database DOES include all subsequent time steps. 3) The NTP code ``handles'' leap seconds by turning the clock back when they happen. By contrast, the timezone code assumes that time_t's are increasing (which they ought to be; I hold that xntpd's behavior is simply wrong). To wit: NTP code wants: Real Time UNIX Time --------------- --------- --------- 30 June 1994, 23:59:59 t s 30 June 1994, 23:59:59 t+1 s 01 July 1994, 00:00:00 t+2 s+1 Timezone code wants: Real Time UNIX Time -------------------- --------- --------- 30 June 1994, 23:59:59 t s 30 June 1994, 23:59:60 t+1 s+1 01 July 1994, 00:00:00 t+2 s+2 A temporary (ugly hack) solution is to use `posix/your/time/zone' rather than `right/your/time/zone' (which is the same as `your/time/zone') for /etc/localtime. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman(a)lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. formerly known as | It is a bond more powerful than absence. We like people wollman(a)emba.uvm.edu | who like Shashish. - Claude McKenzie + Florent Vollant

2 2

Re: 18 sec
by Bradley White March 29, 1994

March 29, 1994

Garrett Wollman <wollman(a)adrastea.lcs.mit.edu> writes: > What you are seeing is the interaction of several different `features' > of NTP and FreeBSD. I'll try to explain, and again hope that somebody > out there can provide a complete solution. Here is an encore of my reply of February 7th. --- Begin forwarded message Date: Mon, 07 Feb 1994 18:05:34 -0500 (EST) From: Bradley White <bww+(a)transarc.com> Subject: Re: leap seconds To: Garrett Wollman <wollman(a)emba.uvm.edu> Cc: Paul Eggert <eggert(a)twinsun.com>, Zone Watchers <tz(a)elsie.nci.nih.gov>, freebsd-tz(a)freefall.cdrom.com Message-Id: <09490.760662334(a)capitol.transarc.com> In-Reply-To: Your message of Mon, 7 Feb 94 17:23:21 -0500 <9402072223.AA23255(a)bajoran.emba.uvm.edu> Any system that runs with ``REDO=right_*'', and which therefore wants to continue to tick normally over leap seconds, needs to do a little bit of work to generate NTP-style timestamps. That is, NTP-style timestamps are discontinuous over leaps, while ``REDO=right_*'' time_t's are continuous. Recent incantations of the `tz' package provide the time2posix() function to help in mapping between these two formats. For example, in the (old, version-1) NTP code, you need to change ... stampp->int_part = htonl(tvp->tv_sec + JAN_1970); to stampp->int_part = htonl(time2posix(tvp->tv_sec) + JAN_1970); I haven't looked at the (new, version-3) XNTP code, but I imagine the change needed there is just as trivial. After that, you will chime NTP harmoniously with the rest of the world, *and*, you will sail smoothly through leap events without the jitter or confusion suffered by your NTP peers. Bradley

1 0

AU Summer time channges (proposed).
by Robert Elz March 29, 1994

March 29, 1994

I'm not in AU right now, and haven't seen the announcementss, though there was talk of changes before I left, but I'm told there is agreement for Vic SA and Tas to switch to summer time on Oct 1, and revert to standard time Mar 31 to give exactly 6 months daylight saving (summer time really) a yearA. One would presume they'd keep the "change on a Sunday" rule, but who knows. Apparently NSW weren't impressed, but may end up changing their minds. I'm sure others in AU can give more details on this. kre

1 0

Re: EU Summer Time update [forwarded with permission]
by ado March 29, 1994

March 29, 1994

> From @doc.memex.co.uk:peter@memex.co.uk Tue Mar 29 08:03:37 1994 > Return-Path: <@doc.memex.co.uk:peter@memex.co.uk> > Received: from relay2.UU.NET by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA09181; Tue, 29 Mar 94 08:03:34 EST > Received: from young.cs.strath.ac.uk by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AAwjia29244; Tue, 29 Mar 94 08:03:28 -0500 > Received: from doc.memex.co.uk by young.cs.strath.ac.uk id aa02542; > 29 Mar 94 14:02 +0100 > Received: by doc.memex.co.uk (4.1/memex_18) > id AA15065; Tue, 29 Mar 94 13:51:13 BST > Date: Tue, 29 Mar 94 13:51:13 BST > From: Peter Ilieve <peter(a)memex.co.uk> > Message-Id: <9403291251.AA15065(a)doc.memex.co.uk> > To: ado(a)elsie.nci.nih.gov > Subject: Re: EU Summer Time update > Status: RO > > > Thanks for the scoop on EU Summer Time. Is it premature to forward it to > > the time zone list? > > ... > > It is the best info available at present. My personal guess is that > nothing will be changed. I have no idea why it has taken since last > September to fail to confirm this directive, nor why it may take until > May. The first change from existing practice is not until October 95, > when the UK/Eire date is Sun>=22 rather than Sun>=23 so it is probably > safe to pass it on, even if you have to correct it later. > > > Peter

1 0

EU Summer Time update [forwarded with permission]
by ado March 29, 1994

March 29, 1994

> From @doc.memex.co.uk:peter@memex.co.uk Mon Mar 28 04:36:25 1994 > Return-Path: <@doc.memex.co.uk:peter@memex.co.uk> > Received: from relay2.UU.NET by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA12705; Mon, 28 Mar 94 04:36:22 EST > Received: from young.cs.strath.ac.uk by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AAwjdu24981; Mon, 28 Mar 94 04:36:08 -0500 > Received: from doc.memex.co.uk by young.cs.strath.ac.uk id aa20721; > 28 Mar 94 10:34 +0100 > Received: by doc.memex.co.uk (4.1/memex_18) > id AA05804; Mon, 28 Mar 94 10:32:19 BST > Date: Mon, 28 Mar 94 10:32:19 BST > From: Peter Ilieve <peter(a)memex.co.uk> > Message-Id: <9403280932.AA05804(a)doc.memex.co.uk> > To: ado(a)elsie.nci.nih.gov > Subject: EU Summer Time update > Status: RO > > I now have a copy of the proposal for the 7th EC directive on summer time > arrangements (COM (93) 439 final, 27 September 1993). This is not yet > a formal directive, treat this as advance warning, some dates may still > change. > > I what looks like a triumph of British obduracy over the poor benighted > foreigners it is proposed to move to a common end date of the 4th Sunday > in October from 1997 so the foreigners will have their winter benightment > postponed by a month. The EC Commission actually asked its tame polling > organisation to conduct one of its Eurobarometer surveys which showed > `that European public opinion is very much in favour of having summer > time extended until the end of October'. > > The dates proposed are: > > 1995: last Sunday in March (26 March) to last Sunday in September (24 Sep) > (UK & Eire ending on 4th Sunday in October (22 Oct)) > 1996: last Sunday in March (31 March) to last Sunday in September (29 Sep) > (UK & Eire ending on 4th Sunday in October (27 Oct)) > 1997: last Sunday in March (30 March) to 4th Sunday in October (26 Oct) > 1998: last Sunday in March (29 March) to 4th Sunday in October (25 Oct) > > The UK/Eire end date of 22 October conflicts with your current rule of > Oct Sun>=23, and the historical UK formula of Sun after 4th Sat. The > last time 4th Sun and Sun after 4th Sat differed was in 1989, when 29 > October was used. That year was covered by a UK Summer Time Order for > only a single year and it looks as though there was a matching 4th EC > directive for just this year. I don't have the text of the 5th EC > directive (for 1990--92) but my guess would be it said 4th Sun. To > maintain strict historical accuracy you could start a new UK ending > rule of Oct Sun>=22 in 1990. A similar rule will be needed for all the > -Eur rules from 1997. > > Negotiations about joinging the EU have been concluded with Austria, > Finland, Norway and Sweden and if the current argument among the existing > members about consequential changes in voting rules can be resolved > they should join on 1 Jan 1995, and will presumably use the same > summer time rules as the existing members. I don't know what they do now. > > As I said, this is only a proposal at present. The EC information office > in Edinburgh could give a guesstimate of when the final version might > emerge. The Home Office guessed at the end of May. > I will keep you posted. > > > Peter Ilieve peter(a)memex.co.uk

1 0

Re: mktime() failures under PCTS testing
by Grant Sullivan March 23, 1994

March 23, 1994

In PCTS, "ambiguous" is referring to the time periods at, and 59:59 minutes after the start of daylight savings, where the time given is as if there were no transition to daylight savings 59:59 minutes before, and at the end of daylight savings, where the time given is as if there were no transition from daylight savings and tm_isdst = -1, assuming the difference between standard vs. daylight is 60:00 minutes. I've run tests on SVR4v3 and HP-UX C.09.01 systems and found their mktime() maps 02:MM:SS/DST-UNKNOWN to 01:MM:SS/DST-OFF I think I prefer 02:MM:SS/DST-UNKNOWN to 03:MM:SS/DST-ON but either mapping is acceptable to PCTS. ------- Forwarded Message Return-Path: bww+(a)transarc.com Received: from sparc51.transarc.com (sparc51.transarc.com, [192.55.207.51]) by transarc.com (5.54/3.15) id <AA06638> for grant(a)osf.org; Wed, 23 Mar 94 14:51:15 EST Received: by sparc51.transarc.com with BradMail(MH 6.8); Wed, 23 Mar 1994 14:51:06 -0500 (EST) To: Grant Sullivan <grant(a)osf.org> Cc: Arthur David Olson <ado(a)elsie.nci.nih.gov> Subject: Re: mktime() failures under PCTS testing In-Reply-To: Your message of Wed, 23 Mar 1994 13:37:01 -0500 Date: Wed, 23 Mar 1994 14:51:05 -0500 (EST) Message-Id: <16001.764452265(a)sparc51.transarc.com> From: Bradley White <bww+(a)transarc.com> > mktime() is failing only those PCTS tests which test "ambiguous" transitions > from standard to daylight time. mktime() passes all the tests for "ambiguous" > transitions from daylight to standard time, however. The first and second senses of the word "ambiguous" should be distinguished. The daylight->standard transition period does indeed include wall-clock times that each correspond to two distinct time_t's. However, the standard->daylight transition period renders wall-clock times that simply do not exist. And now my opinion: I am all for mktime() failing for *all* non-existent times-of-day, but, given that we do `isdst' correction, and map the non-existent times of ... 02:MM:SS/DST-OFF to 03:MM:SS/DST-ON and 02:MM:SS/DST-ON to 01:MM:SS/DST-OFF ..., it seems that we should also map 02:MM:SS/DST-UNKNOWN to one of those. Bradley PS: I won't mention that the test suite assumes too much about time_t's :-). ------- End of Forwarded Message

1 0

Re: mktime() failures under PCTS testing
by ado March 23, 1994

March 23, 1994

The ftpable-from-elsie version of the time zone code suffers the same fate as related by grant@osf; on our SunOS 4.1.1 system, after making this change to the sample code: > SCCS/s.try.c: 1.1 vs. 1.2 > *** 1.1/try.c Tue Mar 22 18:45:08 1994 > --- 1.2/try.c Tue Mar 22 18:45:08 1994 > *************** > *** 34,43 **** > --- 34,53 ---- > printf("mktime test: for this test, set TZ=dst0std,J057,J059\n"); > printf("current value of TZ = %s\n", getenv("TZ")); > > + #if 0 > if (setenv("TZ", TZ_value, 1) != 0) { > printf("resetting TZ failed\n"); > exit(1); > } > + #else > + { > + char buf[512]; > + > + (void) strcpy(buf, "TZ="); > + (void) strcat(buf, TZ_value); > + putenv(buf); > + } > + #endif > printf("new value of TZ = %s\n", getenv("TZ")); > > time_str.tm_year = TM_year - 1900; ...I get these results: > mktime test: PCTS/STD/LS/mktime 8.1.58_9 Assert 5.1.3 > mktime test: for this test, set TZ=dst0std,J057,J059 > current value of TZ = (null) > new value of TZ = std0dst,J057,J059 > time_str tm struct set to: > year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1 > expected value from mktime = 667530000 >>>>> mktime returned -1 (-unknown-) > mktime() final time_str tm struct reset to: > year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1 Vintage time zone hands will recognize this as behavior that certain SunOS versions of the "cron" program clashed with. The time zone package is assuming that the "mktime" call is asking a question such as... If US DST rules are in effect and I'm in the Eastern US, when, on April 3, 1994, will a wall clock show 2:30 a.m. (irrespective of whether it is or isn't daylight saving time)? ...and the "-1" answer is the package's way of saying... There is no such time! If someone has the relevant wording from the current version of the relevant standard(s) on what to do here, I'd love to hear from you. --ado

3 2

mktime() failures under PCTS testing [forwarded with permission]
by ado March 23, 1994

March 23, 1994

> From grant(a)osf.org Tue Mar 22 17:47:33 1994 > Return-Path: <grant(a)osf.org> > Received: from postman.osf.org by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA07444; Tue, 22 Mar 94 17:47:32 EST > Received: from vishnu.osf.org by postman.osf.org (5.64+/OSF 1.0) > id AA27681; Tue, 22 Mar 94 17:47:26 -0500 > Message-Id: <9403222247.AA27681(a)postman.osf.org> > To: ado(a)elsie.nci.nih.gov (Arthur David Olson) > Cc: grant(a)osf.org > Subject: mktime() failures under PCTS testing > Date: Tue, 22 Mar 1994 17:47:21 -0500 > From: Grant Sullivan <grant(a)osf.org> > Status: RO > > > Hi Arthur, > > I am a contractor at the Open Software Foundation, Cambridge, MA, responsible > for helping to make sure that OSF/1 R1.3 utlities and libraries are > conforming to POSIX.1, POSIX.2, XPG4, and other standards. > > My department's QA group recently completed a PCTS test of our current OSF/1 > libc, and reported to me that there were a number of mktime() failures in > PCTS STD/LS/mktime, such as the following: > > 5.<p1>.5.1.1. Preparation [4009] > Setup environment for testing. > > 5.<p1>.5.1.2. Testing [4009] > TZ is of the form: TZ=dst0std,J057,J059 > Non-leap year, one second prior to Jstart_day time. > > MESSAGE (5.<p1>.5.1.2.): > Testing local time of: Tue Feb 26 01:59:59 1991 > PCTS action taken: CONTINUE > > 5.<p1>.5.1.3. Testing [4009] > Non-leap year, at ambiguous Jstart_day time. > > MESSAGE (5.<p1>.5.1.3.): > Testing local time of: Tue Feb 26 02:00:00 1991 > PCTS action taken: CONTINUE > > ERROR (5.<p1>.5.1.3.): > Call to mktime() failed (returned -1). > PCTS action taken: CONTINUE > > ERROR (5.<p1>.5.1.3.): > Incorrect time returned by call to mktime(). > Expected: 667530000 Or: 667533600 > Actual: -1 > PCTS action taken: CONTINUE > > This particular test calls mktime() with tm_isdst set to -1, so it is expecting > mktime() to return either the standard time value (667530000), or the > daylight time value (667533600), under the apparent assumption that if > tm_isdst == -1, then mktime() would attempt to determine if tm_isdst should be > 0 or 1 and return the proper seconds, and adjust the struct tm accordingly. > > Our current OSF/1 libc ctime.c is based on BSD 4.4-alpha snapshot > "@(#)ctime.c 5.26 (Berkeley) 2/23/91" > with additional fixes from your June'93 kit: > elsieid[] = "@(#)localtime.c 7.9" > plus some other adjustments. > > There are quite a few PCTS failures, but I think they all boil down to a common > cause: mktime() returns -1 when tm_isdst = -1 and the tm structure specifies > the daylight savings time day, and a time at or within the first hour of > daylight savings time. > > I have created a simple test program, based on the XPG4 mktime() example, > which exercises the first PCTS failure case above. I've tried this on > several systems which have older versions of the Zoneinfo package, and on > several systems which don't have the package. I got the same failure on the > older Zoneinfo systems I tested, and mktime() returned 667530000, and set > tm_isdst to 0 on the several systems I tested which don't use the package. > > My own interpretation of the XPG4 and POSIX.2 standards suggest that mktime() > should return 667533600, and reset the passed tm_isdst to 1, under the belief > that for the above case, daylight savings starts exactly at > Tue Feb 26 02:00:00 1991 > for TZ=dst0std,J057,J059, instead of after this time, i.e. instead of at > Tue Feb 26 02:00:01 1991 > > A friend of mine at another company told me he had run into similar mktime() > problems with the FIPS151-2 test suite. He made alterations which resulted > in mktime() returning 667533600, and tm_isdst reset to 1, so we both have the > same interpretations of the XPG4 and POSIX.1 standards. His version of > mktime() was based on something older than your June'93 kit. > > I am wondering what mktime() in your current kit does in this case? Do you > think it should return: > > -1 , tm_isdst = -1 > or 667530000, tm_isdst = 0 > or 667533600, tm_isdst = 1 > > ? > > I am attaching a test program. > > Thanks very much for your help, > > Grant W. Sullivan, grant(a)osf.org > Open Software Foundation > 11 Cambridge Center, > Cambridge, MA 02142 > > > mktime_XPG4_example.c > ========================================================================== > /* XPG4, pg. 276 mktime() example > * > * with input data from PCTS STD/LS/mktime 8.1.58_09 5.1.3 test > * > */ > > #include <stdio.h> > #include <time.h> > > #include <stdlib.h> > > struct tm time_str; > > char daybuf[20]; > > /* values for struct tm; from PCTS STD/LS/mktime 8.1.58_09.c */ > #define TZ_value "std0dst,J057,J059" > #define TM_year 1991 /* non-leap year */ > #define TM_mon 2 /* dst start month -- February */ > #define TM_mday 26 /* dst start day J057 non-leap year */ > #define TM_hour 2 /* for J057 dst start hour */ > #define TM_min 0 /* for J057 dst start hour/min */ > #define TM_sec 0 /* for J057 dst start hour/min/sec */ > #define TM_wday -1 /* don't know */ > #define TM_yday -1 /* don't know */ > #define TM_isdst -1 /* don't know if std or dst */ > #define MKTIME_expected 667530000L > > > main() > { > time_t mktime_returned; > > printf("mktime test: PCTS/STD/LS/mktime 8.1.58_9 Assert 5.1.3\n"); > printf("mktime test: for this test, set TZ=dst0std,J057,J059\n"); > printf("current value of TZ = %s\n", getenv("TZ")); > > if (setenv("TZ", TZ_value, 1) != 0) { > printf("resetting TZ failed\n"); > exit(1); > } > printf("new value of TZ = %s\n", getenv("TZ")); > > time_str.tm_year = TM_year - 1900; > time_str.tm_mon = TM_mon - 1; > time_str.tm_mday = TM_mday; > time_str.tm_hour = TM_hour; > time_str.tm_min = TM_min; > time_str.tm_sec = TM_sec; > time_str.tm_wday = TM_wday; > time_str.tm_yday = TM_yday; > time_str.tm_isdst = TM_isdst; > > printf("time_str tm struct set to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > printf("expected value from mktime = %d\n", MKTIME_expected); > > if ((mktime_returned = mktime(&time_str)) == (time_t)-1) { > (void)puts("mktime returned -1 (-unknown-)"); > printf("mktime() final time_str tm struct reset to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > exit(1); > } > else { > printf("mktime returned value = %d\n", (int) mktime_returned); > printf("mktime() final time_str tm struct reset to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > > (void)strftime(daybuf, sizeof(daybuf), "%A", &time_str); > (void)puts(daybuf); > } > > exit(0); > } > ==========================================================================

2 1

Re: Does anyone have the source for this function?
by myersn＠roguewave.com March 23, 1994

March 23, 1994

> Does anyone have a UNIX function for converting a time from timezoneX > to timezoneY? I know how to write this by mucking with char** environ > and by calling tzset(), but I'm interested in a more elegant solution > (perhaps using fields in the tm structure). > > convert(timezoneX, timezoneY, inputTime, outputTime) > > The char** environ solution seems to me to be inelegant because > > 1) I have to reread a file whenever I call tzset() (I think), > and > > 2) while I'm doing the conversion the call to tzset() has a > global effect on my process. If I'm interrupted by a > signal handler that displays the time it will be in a > foreign timezone. My current best solution is to use the Rogue Wave Tools.h++ library class RWZone. Nathan Myers myersn(a)roguewave.com

1 0

Does anyone have the source for this function?
by aaron＠lehman.com March 22, 1994

March 22, 1994

Does anyone have a UNIX function for converting a time from timezoneX to timezoneY? I know how to write this by mucking with char** environ and by calling tzset(), but I'm interested in a more elegant solution (perhaps using fields in the tm structure). convert(timezoneX, timezoneY, inputTime, outputTime) The char** environ solution seems to me to be inelegant because 1) I have to reread a file whenever I call tzset() (I think), and 2) while I'm doing the conversion the call to tzset() has a global effect on my process. If I'm interrupted by a signal handler that displays the time it will be in a foreign timezone. aaron(a)lehman.com

1 0

Time Conversoin Question [forwarded with permission]
by ado March 21, 1994

March 21, 1994

> From aaron(a)lehman.com Thu Mar 17 16:49:11 1994 > Return-Path: <aaron(a)lehman.com> > Received: from lehman.com by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA28619; Thu, 17 Mar 94 16:49:08 EST > Received: from relay.lehman.com by lehman.com (8.6.4/LB 0.1) > id QAA19119; Thu, 17 Mar 1994 16:48:58 -0500 > Received: from killer.lehman.com by relay.lehman.com (4.1/LB-0.6) > id AA04769; Thu, 17 Mar 94 16:48:51 EST > Received: from yen.lehman.com by killer.lehman.com (5.0/SMI-SVR4) > id AA29096; Thu, 17 Mar 1994 16:48:48 +0500 > Date: Thu, 17 Mar 1994 16:48:48 +0500 > From: aaron(a)lehman.com (Aaron Akman) > Message-Id: <9403172148.AA29096(a)killer.lehman.com> > Received: by yen.lehman.com (4.1/SMI-4.1) > id AA03187; Thu, 17 Mar 94 16:48:45 EST > To: ado(a)elsie.nci.nih.gov > Subject: Time Conversion Question > Content-Length: 1037 > Status: RO > > Arthur, > > I've downloaded your timezone stuff (got pointers from Arnold Robbins > and Don Libes), and have a question: > > I'm looking to convert from GMT to one of a few timezones, or from one > timezone to another. I'm concerned about setting TZ and calling > tzset() because I think it changes some global state associated with > the process. If I were interrupted before setting TZ back and > re-calling tzset(), I could have an interrupt function that doesn't > have the right local TZ setting. I.e. > > get_other_local_time(char* tzsetting) > { > oldsetting = temporarily_set_TZ(tzsetting); > tzset(); > > do_time_stuff_with_alternate_TZ(); > > /* i could get interrupted here by a signal handler > that needs the real local time!! */ > > set_TZ_back(oldsetting); > tzset(); > } > > Is there a better way? Is it true the effect of tzset() global? I > haven't gone through the .c files in depth yet. > > It seems like this should be a common problem for a globally > distributed system. > > Thanks in advance for any advice, > Aaron Akman > aaron(a)lehman.com > 212 464 3978

1 0

%V [forwarded]
by ado Feb. 28, 1994

Feb. 28, 1994

> From arnold(a)skeeve.atl.ga.us Sat Feb 26 21:12:21 1994 > Received: from emory.mathcs.emory.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA18459; Sat, 26 Feb 94 21:12:18 EST > Received: from skeeve.UUCP by > emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.19) via UUCP > id AA09626 ; Sat, 26 Feb 94 21:12:14 -0500 > Return-Path: arnold(a)skeeve.atl.ga.us > Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) > id <m0paal5-00013rC(a)skeeve.atl.ga.us>; Sat, 26 Feb 94 20:57 EST > Message-Id: <m0paal5-00013rC(a)skeeve.atl.ga.us> > From: arnold(a)skeeve.atl.ga.us > Date: Sat, 26 Feb 1994 20:57:26 -0500 > X-Ultrix: Just Say NO! > X-Important-Saying: Premature Optimization Is The Root Of All Evil. > X-Mailer: Mail User's Shell (7.2.5 10/14/92) > To: ado(a)elsie.nci.nih.gov > Subject: any comment on this? > Status: RO > > --- Forwarded mail from Tor Lillqvist <emory!tik.vtt.fi!tml> > > >From emory!tik.vtt.fi!tml Wed Feb 23 08:12:20 1994 > Return-Path: <emory!tik.vtt.fi!tml> > Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) > id <m0pZJNz-00013zC(a)skeeve.atl.ga.us>; Wed, 23 Feb 94 08:12 EST > Received: from tiuhti.tik.vtt.fi by > emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.19) via SMTP > id AA26972 ; Wed, 23 Feb 94 08:07:40 -0500 > Received: from localhost (tml@localhost) by tiuhti.tik.vtt.fi (8.6.5/8.6.5) id PAA28498; Wed, 23 Feb 1994 15:07:33 +0200 > Date: Wed, 23 Feb 1994 15:07:33 +0200 > From: Tor Lillqvist <emory!tik.vtt.fi!tml> > Message-Id: <199402231307.PAA28498(a)tiuhti.tik.vtt.fi> > To: arnold(a)skeeve.atl.ga.us (Arnold Robbins) > In-Reply-To: arnold(a)skeeve.atl.ga.us's message of 22 Feb 1994 17:21:29 -0800 > Subject: v27i207: strftime-6.0 - yet another strftime(3) and date(1), Part01/01 > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > >>>>> On 22 Feb 1994 17:21:29 -0800, arnold(a)skeeve.atl.ga.us (Arnold Robbins) said: > > (to wit: if the week containing January 1 has four or more > > days in the new year, then it is week 1, otherwise it is > > week 53 of the previous year and the next week is week 1). > > Nope, it can also be week 52 of the previous year. For instance this > year's (1994) January 1st an 2nd were in week 52 of 1993. "The highest > numbered week of the previous year (52 or 53)" would be more correct. > > I guess you really need a format character for "what year does the > week number output by %V refer to", also. Otherwise it's hard to find > any good use for the %V format in a program or script. If, for > instance, you use `date +%V` to form the name of a weekly log file > accumulated daily, then the logging from January 1 and 2 in 1994 > should go to the log file for week 52 of 1993, not to the log file for > week 52 of 1994... > > > --- End of forwarded message from Tor Lillqvist <emory!tik.vtt.fi!tml>

1 0

tzcode94d.tar.gz and tzdata94d.tar.gz
by ado Feb. 24, 1994

Feb. 24, 1994

The files tzcode94d.tar.gz and tzdata94d.tar.gz are now available for anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (128.231.16.1). These files incorporate the changes to avoid clashes with POSIX semantics for zones such as GMT+4; some other very minor housekeeping is also present. --ado

1 0

v27i207: strftime-6.0 - yet another strftime(3) and date(1), Part01/01
by Monty Solomon Feb. 23, 1994

Feb. 23, 1994

Begin forwarded message: Path: decwrl!vixie!vixie!not-for-mail From: arnold(a)skeeve.atl.ga.us (Arnold Robbins) Newsgroups: comp.sources.unix Subject: v27i207: strftime-6.0 - yet another strftime(3) and date(1), Part01/01 Date: 22 Feb 1994 17:21:29 -0800 Organization: Vixie Enterprises Lines: 1245 Sender: vixie(a)vix.com Approved: vixie(a)gw.home.vix.com Nntp-Posting-Host: gw.home.vix.com To: unix-sources(a)pa.dec.com Submitted-By: arnold(a)skeeve.atl.ga.us (Arnold Robbins) Posting-Number: Volume 27, Issue 207 Archive-Name: strftime-6.0/part01 [ this recurring package is the cleanest, nicest date(1) and strftime(3) i have ever seen, including all free or vendor systems. --vix ] It seems to be an annual event, something in the circling of the stars overhead, that requires me to post this, at least once a year. (:-) This version fixes bugs in the calculations for %U, %W, and %V and output formats of several of the others (they now have leading zeros if necessary). It also fixes a small bug in date.c. Although this is only the fourth version posted c.s.u, it is the sixth one to go to the net, the first two were in comp.sources.misc. So I don't know if this is strftime 4.0 or 6.0, you can decide. I sincerely hope this will be it (at least 'til next year! :-) Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold(a)skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins #! /bin/sh echo - 'README' cat << 'EOF' > 'README' Tue Feb 15 08:26:04 EST 1994 This package implements the Posix 1003.2 date command, as a wrapper around an extended version of the ANSI strftime(3) library routine. Everything in it is public domain. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold(a)skeeve.ATL.GA.US | exponentially in the UUCP: { gatech, emory }!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins EOF echo - 'Makefile' cat << 'EOF' > 'Makefile' # Makefile for PD date and strftime SRCS= date.c strftime.c OBJS= date.o strftime.o DOCS= date.1 strftime.3 # Uncomment the define of HAVE_TZNAME if your system has the tzname[] array. # Uncomment the define of TM_IN_SYS_TIME if struct tm is in <sys/time.h> CFLAGS= -O #-DHAVE_TZNAME #-DTM_IN_SYS_TIME date: $(OBJS) $(CC) $(CFLAGS) $(OBJS) -o $@ date.o: date.c strftime.o: strftime.c EOF echo - 'date.1' cat << 'EOF' > 'date.1' .TH DATE 1 .SH NAME date \- write the date and time .SH SYNOPSIS .B date [ .B \-u ] [ .RI + format ] .SH DESCRIPTION .I Date writes the current date and time to the standard output. It is intended to be compliant with draft 11 of the Posix 1003.2 Command Language and Utilities standard. Therefore, it is purposely .I not usable by the super-user for setting the system time. .LP .I Date accepts one option: .TP .B \-u Perform operations as if the .B TZ environment variable was set to .BR GMT0 . .LP If an argument to .I date is given that begins with a ``+'', then the output is controlled by the contents of the rest of the string. Normal text is output unmodified, while field descriptors in the format string are substituted for. .LP The .I date program is essentially a wrapper around .IR strftime (3); see there for a description of the available formatting options. .LP If no format string is given, or if it does not begin with a ``+'', then the default format of \fB"%a %b %e %H:%M:%S %Z %Y"\fR will be used. This produces the traditional style of output, such as ``Sun Mar 17 10:32:47 EST 1991''. .SH SEE ALSO time(2), strftime(3), localtime(3) .SH BUGS This version only works for the POSIX locale. .SH AUTHOR .nf Arnold Robbins .sp INTERNET: arnold(a)skeeve.atl.ga.us UUCP: emory!skeeve!arnold Phone: +1 404 248 9324 .fi EOF echo - 'date.c' cat << 'EOF' > 'date.c' /* * date.c * * Public domain implementation of Posix 1003.2 * date command. Lets strftime() do the dirty work. * * Arnold Robbins * arnold(a)skeeve.atl.ga.us * April, 1991 * * Bug fix courtesy of Chris Ritson (C.R.Ritson(a)newcastle.ac.uk) * February, 1994. */ #include <stdio.h> #include <sys/types.h> #include <time.h> extern char *malloc(); extern size_t strftime(); extern int getopt(); extern int optind; int main(argc, argv) int argc; char **argv; { time_t clock; struct tm *now; int c, size, ret; char *defhow = "%a %b %e %H:%M:%S %Z %Y"; char *howto = defhow; char *buf; while ((c = getopt(argc, argv, "u")) != -1) switch (c) { case 'u': putenv("TZ=GMT0"); break; default: fprintf(stderr, "usage: %s [-u] [+format_str]\n", argv[0]); exit(1); } time(& clock); now = localtime(& clock); if (optind < argc && argv[optind][0] == '+') howto = & argv[optind][1]; size = strlen(howto) * 10; if (size < 26) size = 26; if ((buf = malloc(size)) == NULL) { perror("not enough memory"); exit(1); } ret = strftime(buf, size, howto, now); if (ret != 0) printf("%s\n", buf); else { fprintf(stderr, "conversion failed\n"); exit(1); } exit(0); } EOF echo - 'strftime.3' cat << 'EOF' > 'strftime.3' .TH STRFTIME 3 .SH NAME strftime \- generate formatted time information .SH SYNOPSIS .ft B .nf #include <sys/types.h> #include <time.h> .sp size_t strftime(char *s, size_t maxsize, const char *format, const struct tm *timeptr); .SH DESCRIPTION The following description is transcribed verbatim from the December 7, 1988 draft standard for ANSI C. This draft is essentially identical in technical content to the final version of the standard. .LP The .B strftime function places characters into the array pointed to by .B s as controlled by the string pointed to by .BR format . The format shall be a multibyte character sequence, beginning and ending in its initial shift state. The .B format string consists of zero or more conversion specifiers and ordinary multibyte characters. A conversion specifier consists of a .B % character followed by a character that determines the behavior of the conversion specifier. All ordinary multibyte characters (including the terminating null character) are copied unchanged into the array. If copying takes place between objects that overlap the behavior is undefined. No more than .B maxsize characters are placed into the array. Each conversion specifier is replaced by appropriate characters as described in the following list. The appropriate characters are determined by the .B LC_TIME category of the current locale and by the values contained in the structure pointed to by .BR timeptr . .TP .B %a is replaced by the locale's abbreviated weekday name. .TP .B %A is replaced by the locale's full weekday name. .TP .B %b is replaced by the locale's abbreviated month name. .TP .B %B is replaced by the locale's full month name. .TP .B %c is replaced by the locale's appropriate date and time representation. .TP .B %d is replaced by the day of the month as a decimal number .RB ( 01 - 31 ). .TP .B %H is replaced by the hour (24-hour clock) as a decimal number .RB ( 00 - 23 ). .TP .B %I is replaced by the hour (12-hour clock) as a decimal number .RB ( 01 - 12 ). .TP .B %j is replaced by the day of the year as a decimal number .RB ( 001 - 366 ). .TP .B %m is replaced by the month as a decimal number .RB ( 01 - 12 ). .TP .B %M is replaced by the minute as a decimal number .RB ( 00 - 59 ). .TP .B %p is replaced by the locale's equivalent of the AM/PM designations associated with a 12-hour clock. .TP .B %S is replaced by the second as a decimal number .RB ( 00 - 61 ). .TP .B %U is replaced by the week number of the year (the first Sunday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). .TP .B %w is replaced by the weekday as a decimal number .RB [ "0 " (Sunday)- 6 ]. .TP .B %W is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). .TP .B %x is replaced by the locale's appropriate date representation. .TP .B %X is replaced by the locale's appropriate time representation. .TP .B %y is replaced by the year without century as a decimal number .RB ( 00 - 99 ). .TP .B %Y is replaced by the year with century as a decimal number. .TP .B %Z is replaced by the time zone name or abbreviation, or by no characters if no time zone is determinable. .TP .B %% is replaced by .BR % . .LP If a conversion specifier is not one of the above, the behavior is undefined. .SH RETURNS If the total number of resulting characters including the terminating null character is not more than .BR maxsize , the .B strftime function returns the number of characters placed into the array pointed to by .B s not including the terminating null character. Otherwise, zero is returned and the contents of the array are indeterminate. .SH NON-ANSI EXTENSIONS If .B SYSV_EXT is defined when the routine is compiled, then the following additional conversions will be available. These are borrowed from the System V .IR cftime (3) and .IR ascftime (3) routines. .TP .B %D is equivalent to specifying .BR %m/%d/%y . .TP .B %e is replaced by the day of the month, padded with a blank if it is only one digit. .TP .B %h is equivalent to .BR %b , above. .TP .B %n is replaced with a newline character (\s-1ASCII LF\s+1). .TP .B %r is equivalent to specifying .BR "%I:%M:%S %p" . .TP .B %R is equivalent to specifying .BR %H:%M . .TP .B %T is equivalent to specifying .BR %H:%M:%S . .TP .B %t is replaced with a \s-1TAB\s+1 character. .PP If .B SUNOS_EXT is defined when the routine is compiled, then the following additional conversions will be available. These are borrowed from the SunOS version of .IR strftime . .TP .B %k is replaced by the hour (24-hour clock) as a decimal number .RB ( 0 - 23 ). Single digit numbers are padded with a blank. .TP .B %l is replaced by the hour (12-hour clock) as a decimal number .RB ( 1 - 12 ). Single digit numbers are padded with a blank. .SH POSIX 1003.2 EXTENSIONS If .B POSIX2_DATE is defined, then all of the conversions available with .B SYSV_EXT and .B SUNOS_EXT are available, as well as the following additional conversions: .TP .B %C The century, as a number between 00 and 99. .TP .B %u is replaced by the weekday as a decimal number .RB [ "1 " (Monday)- 7 ]. .TP .B %V is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 01 - 53 ). The method for determining the week number is as specified by ISO 8601 (to wit: if the week containing January 1 has four or more days in the new year, then it is week 1, otherwise it is week 53 of the previous year and the next week is week 1). .LP The text of the POSIX standard for the .I date utility describes .B %U and .B %W this way: .TP .B %U is replaced by the week number of the year (the first Sunday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). All days in a new year preceding the first Sunday are considered to be in week 0. .TP .B %W is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). All days in a new year preceding the first Monday are considered to be in week 0. .LP In addition, the alternate representations .BR %Ec , .BR %EC , .BR %Ex , .BR %Ey , .BR %EY , .BR %Od , .BR %Oe , .BR %OH , .BR %OI , .BR %Om , .BR %OM , .BR %OS , .BR %Ou , .BR %OU , .BR %OV , .BR %Ow , .BR %OW , and .B %Oy are recognized, but their normal representations are used. .SH VMS EXTENSIONS If .B VMS_EXT is defined, then the following additional conversion is available: .TP .B %v The date in VMS format (e.g. 20-JUN-1991). .SH SEE ALSO .IR time (2), .IR ctime (3), .IR localtime (3), .IR tzset (3) .SH BUGS This version does not handle multibyte characters or pay attention to the setting of the .B LC_TIME environment variable. .LP It is not clear what is ``appropriate'' for the C locale; the values returned are a best guess on the author's part. .SH CAVEATS The pre-processor symbol .B POSIX_SEMANTICS is automatically defined, which forces the code to call .IR tzset (3) whenever the .B TZ environment variable has changed. If this routine will be used in an application that will not be changing .BR TZ , then there may be some performance improvements by not defining .BR POSIX_SEMANTICS . .SH AUTHOR .nf Arnold Robbins .sp INTERNET: arnold(a)skeeve.atl.ga.us UUCP: emory!skeeve!arnold Phone: +1 404 248 9324 .fi .SH ACKNOWLEDGEMENTS Thanks to Geoff Clare <gwc(a)root.co.uk> for helping debug earlier versions of this routine, and for advice about POSIX semantics. Additional thanks to Arthur David Olsen <ado(a)elsie.nci.nih.gov> for some code improvements. Thanks also to Tor Lillqvist <tml(a)tik.vtt.fi> for code fixes to the ISO 8601 code. EOF echo - 'strftime.c' cat << 'EOF' > 'strftime.c' /* * strftime.c * * Public-domain implementation of ANSI C library routine. * * It's written in old-style C for maximal portability. * However, since I'm used to prototypes, I've included them too. * * If you want stuff in the System V ascftime routine, add the SYSV_EXT define. * For extensions from SunOS, add SUNOS_EXT. * For stuff needed to implement the P1003.2 date command, add POSIX2_DATE. * For VMS dates, add VMS_EXT. * For complete POSIX semantics, add POSIX_SEMANTICS. * * The code for %c, %x, and %X is my best guess as to what's "appropriate". * This version ignores LOCALE information. * It also doesn't worry about multi-byte characters. * So there. * * This file is also shipped with GAWK (GNU Awk), gawk specific bits of * code are included if GAWK is defined. * * Arnold Robbins * January, February, March, 1991 * Updated March, April 1992 * Updated April, 1993 * Updated February, 1994 * * Fixes from ado(a)elsie.nci.nih.gov * February 1991, May 1992 * Fixes from Tor Lillqvist tml(a)tik.vtt.fi * May, 1993 * Further fixes from ado(a)elsie.nci.nih.gov * February 1994 */ #ifndef GAWK #include <stdio.h> #include <ctype.h> #include <string.h> #include <time.h> #endif #include <sys/types.h> #if defined(TM_IN_SYS_TIME) || ! defined(GAWK) #include <sys/time.h> #endif /* defaults: season to taste */ #define SYSV_EXT 1 /* stuff in System V ascftime routine */ #define SUNOS_EXT 1 /* stuff in SunOS strftime routine */ #define POSIX2_DATE 1 /* stuff in Posix 1003.2 date command */ #define VMS_EXT 1 /* include %v for VMS date format */ #ifndef GAWK #define POSIX_SEMANTICS 1 /* call tzset() if TZ changes */ #endif #if defined(POSIX2_DATE) #if ! defined(SYSV_EXT) #define SYSV_EXT 1 #endif #if ! defined(SUNOS_EXT) #define SUNOS_EXT 1 #endif #endif #if defined(POSIX2_DATE) #define adddecl(stuff) stuff #else #define adddecl(stuff) #endif #undef strchr /* avoid AIX weirdness */ #ifndef __STDC__ #define const /**/ extern void *malloc(); extern void *realloc(); extern void tzset(); extern char *strchr(); extern char *getenv(); static int weeknumber(); adddecl(static int iso8601wknum();) #else extern void *malloc(unsigned count); extern void *realloc(void *ptr, unsigned count); extern void tzset(void); extern char *strchr(const char *str, int ch); extern char *getenv(const char *v); static int weeknumber(const struct tm *timeptr, int firstweekday); adddecl(static int iso8601wknum(const struct tm *timeptr);) #endif #ifdef __GNUC__ #define inline __inline__ #else #define inline /**/ #endif #define range(low, item, hi) max(low, min(item, hi)) #if !defined(OS2) && !defined(MSDOS) && defined(HAVE_TZNAME) extern char *tzname[2]; extern int daylight; #endif /* min --- return minimum of two numbers */ #ifndef __STDC__ static inline int min(a, b) int a, b; #else static inline int min(int a, int b) #endif { return (a < b ? a : b); } /* max --- return maximum of two numbers */ #ifndef __STDC__ static inline int max(a, b) int a, b; #else static inline int max(int a, int b) #endif { return (a > b ? a : b); } /* strftime --- produce formatted time */ #ifndef __STDC__ size_t strftime(s, maxsize, format, timeptr) char *s; size_t maxsize; const char *format; const struct tm *timeptr; #else size_t strftime(char *s, size_t maxsize, const char *format, const struct tm *timeptr) #endif { char *endp = s + maxsize; char *start = s; auto char tbuf[100]; int i; static short first = 1; #ifdef POSIX_SEMANTICS static char *savetz = NULL; static int savetzlen = 0; char *tz; #endif /* POSIX_SEMANTICS */ /* various tables, useful in North America */ static const char *days_a[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", }; static const char *days_l[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", }; static const char *months_a[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", }; static const char *months_l[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; static const char *ampm[] = { "AM", "PM", }; if (s == NULL || format == NULL || timeptr == NULL || maxsize == 0) return 0; /* quick check if we even need to bother */ if (strchr(format, '%') == NULL && strlen(format) + 1 >= maxsize) return 0; #ifndef POSIX_SEMANTICS if (first) { tzset(); first = 0; } #else /* POSIX_SEMANTICS */ tz = getenv("TZ"); if (first) { if (tz != NULL) { int tzlen = strlen(tz); savetz = (char *) malloc(tzlen + 1); if (savetz != NULL) { savetzlen = tzlen + 1; strcpy(savetz, tz); } } tzset(); first = 0; } /* if we have a saved TZ, and it is different, recapture and reset */ if (tz && savetz && (tz[0] != savetz[0] || strcmp(tz, savetz) != 0)) { i = strlen(tz) + 1; if (i > savetzlen) { savetz = (char *) realloc(savetz, i); if (savetz) { savetzlen = i; strcpy(savetz, tz); } } else strcpy(savetz, tz); tzset(); } #endif /* POSIX_SEMANTICS */ for (; *format && s < endp - 1; format++) { tbuf[0] = '\0'; if (*format != '%') { *s++ = *format; continue; } again: switch (*++format) { case '\0': *s++ = '%'; goto out; case '%': *s++ = '%'; continue; case 'a': /* abbreviated weekday name */ if (timeptr->tm_wday < 0 || timeptr->tm_wday > 6) strcpy(tbuf, "?"); else strcpy(tbuf, days_a[timeptr->tm_wday]); break; case 'A': /* full weekday name */ if (timeptr->tm_wday < 0 || timeptr->tm_wday > 6) strcpy(tbuf, "?"); else strcpy(tbuf, days_l[timeptr->tm_wday]); break; #ifdef SYSV_EXT case 'h': /* abbreviated month name */ #endif case 'b': /* abbreviated month name */ if (timeptr->tm_mon < 0 || timeptr->tm_mon > 11) strcpy(tbuf, "?"); else strcpy(tbuf, months_a[timeptr->tm_mon]); break; case 'B': /* full month name */ if (timeptr->tm_mon < 0 || timeptr->tm_mon > 11) strcpy(tbuf, "?"); else strcpy(tbuf, months_l[timeptr->tm_mon]); break; case 'c': /* appropriate date and time representation */ sprintf(tbuf, "%s %s %2d %02d:%02d:%02d %d", days_a[range(0, timeptr->tm_wday, 6)], months_a[range(0, timeptr->tm_mon, 11)], range(1, timeptr->tm_mday, 31), range(0, timeptr->tm_hour, 23), range(0, timeptr->tm_min, 59), range(0, timeptr->tm_sec, 61), timeptr->tm_year + 1900); break; case 'd': /* day of the month, 01 - 31 */ i = range(1, timeptr->tm_mday, 31); sprintf(tbuf, "%02d", i); break; case 'H': /* hour, 24-hour clock, 00 - 23 */ i = range(0, timeptr->tm_hour, 23); sprintf(tbuf, "%02d", i); break; case 'I': /* hour, 12-hour clock, 01 - 12 */ i = range(0, timeptr->tm_hour, 23); if (i == 0) i = 12; else if (i > 12) i -= 12; sprintf(tbuf, "%02d", i); break; case 'j': /* day of the year, 001 - 366 */ sprintf(tbuf, "%03d", timeptr->tm_yday + 1); break; case 'm': /* month, 01 - 12 */ i = range(0, timeptr->tm_mon, 11); sprintf(tbuf, "%02d", i + 1); break; case 'M': /* minute, 00 - 59 */ i = range(0, timeptr->tm_min, 59); sprintf(tbuf, "%02d", i); break; case 'p': /* am or pm based on 12-hour clock */ i = range(0, timeptr->tm_hour, 23); if (i < 12) strcpy(tbuf, ampm[0]); else strcpy(tbuf, ampm[1]); break; case 'S': /* second, 00 - 61 */ i = range(0, timeptr->tm_sec, 61); sprintf(tbuf, "%02d", i); break; case 'U': /* week of year, Sunday is first day of week */ sprintf(tbuf, "%02d", weeknumber(timeptr, 0)); break; case 'w': /* weekday, Sunday == 0, 0 - 6 */ i = range(0, timeptr->tm_wday, 6); sprintf(tbuf, "%d", i); break; case 'W': /* week of year, Monday is first day of week */ sprintf(tbuf, "%02d", weeknumber(timeptr, 1)); break; case 'x': /* appropriate date representation */ sprintf(tbuf, "%s %s %2d %d", days_a[range(0, timeptr->tm_wday, 6)], months_a[range(0, timeptr->tm_mon, 11)], range(1, timeptr->tm_mday, 31), timeptr->tm_year + 1900); break; case 'X': /* appropriate time representation */ sprintf(tbuf, "%02d:%02d:%02d", range(0, timeptr->tm_hour, 23), range(0, timeptr->tm_min, 59), range(0, timeptr->tm_sec, 61)); break; case 'y': /* year without a century, 00 - 99 */ i = timeptr->tm_year % 100; sprintf(tbuf, "%02d", i); break; case 'Y': /* year with century */ sprintf(tbuf, "%d", 1900 + timeptr->tm_year); break; case 'Z': /* time zone name or abbrevation */ #ifdef HAVE_TZNAME i = (daylight && timeptr->tm_isdst); /* 0 or 1 */ strcpy(tbuf, tzname[i]); #else strcpy(tbuf, timeptr->tm_zone); #endif break; #ifdef SYSV_EXT case 'n': /* same as \n */ tbuf[0] = '\n'; tbuf[1] = '\0'; break; case 't': /* same as \t */ tbuf[0] = '\t'; tbuf[1] = '\0'; break; case 'D': /* date as %m/%d/%y */ strftime(tbuf, sizeof tbuf, "%m/%d/%y", timeptr); break; case 'e': /* day of month, blank padded */ sprintf(tbuf, "%2d", range(1, timeptr->tm_mday, 31)); break; case 'r': /* time as %I:%M:%S %p */ strftime(tbuf, sizeof tbuf, "%I:%M:%S %p", timeptr); break; case 'R': /* time as %H:%M */ strftime(tbuf, sizeof tbuf, "%H:%M", timeptr); break; case 'T': /* time as %H:%M:%S */ strftime(tbuf, sizeof tbuf, "%H:%M:%S", timeptr); break; #endif #ifdef SUNOS_EXT case 'k': /* hour, 24-hour clock, blank pad */ sprintf(tbuf, "%2d", range(0, timeptr->tm_hour, 23)); break; case 'l': /* hour, 12-hour clock, 1 - 12, blank pad */ i = range(0, timeptr->tm_hour, 23); if (i == 0) i = 12; else if (i > 12) i -= 12; sprintf(tbuf, "%2d", i); break; #endif #ifdef VMS_EXT case 'v': /* date as dd-bbb-YYYY */ sprintf(tbuf, "%02d-%3.3s-%4d", range(1, timeptr->tm_mday, 31), months_a[range(0, timeptr->tm_mon, 11)], timeptr->tm_year + 1900); for (i = 3; i < 6; i++) if (islower(tbuf[i])) tbuf[i] = toupper(tbuf[i]); break; #endif #ifdef POSIX2_DATE case 'C': sprintf(tbuf, "%02d", (timeptr->tm_year + 1900) / 100); break; case 'E': case 'O': /* POSIX locale extensions, ignored for now */ goto again; case 'V': /* week of year according ISO 8601 */ #if defined(GAWK) && defined(VMS_EXT) { extern int do_lint; extern void warning(); static int warned = 0; if (! warned && do_lint) { warned = 1; warning( "conversion %%V added in P1003.2; for VMS style date, use %%v"); } } #endif sprintf(tbuf, "%02d", iso8601wknum(timeptr)); break; case 'u': /* ISO 8601: Weekday as a decimal number [1 (Monday) - 7] */ sprintf(tbuf, "%d", timeptr->tm_wday == 0 ? 7 : timeptr->tm_wday); break; #endif /* POSIX2_DATE */ default: tbuf[0] = '%'; tbuf[1] = *format; tbuf[2] = '\0'; break; } i = strlen(tbuf); if (i) { if (s + i < endp - 1) { strcpy(s, tbuf); s += i; } else return 0; } } out: if (s < endp && *format == '\0') { *s = '\0'; return (s - start); } else return 0; } #ifdef POSIX2_DATE /* iso8601wknum --- compute week number according to ISO 8601 */ #ifndef __STDC__ static int iso8601wknum(timeptr) const struct tm *timeptr; #else static int iso8601wknum(const struct tm *timeptr) #endif { /* * From 1003.2: * If the week (Monday to Sunday) containing January 1 * has four or more days in the new year, then it is week 1; * otherwise it is week 53 of the previous year, and the * next week is week 1. * * ADR: This means if Jan 1 was Monday through Thursday, * it was week 1, otherwise week 53. */ int weeknum, jan1day, diff; /* get week number, Monday as first day of the week */ weeknum = weeknumber(timeptr, 1); /* * With thanks and tip of the hatlo to tml(a)tik.vtt.fi * * What day of the week does January 1 fall on? * We know that * (timeptr->tm_yday - jan1.tm_yday) MOD 7 == * (timeptr->tm_wday - jan1.tm_wday) MOD 7 * and that * jan1.tm_yday == 0 * and that * timeptr->tm_wday MOD 7 == timeptr->tm_wday * from which it follows that. . . */ jan1day = timeptr->tm_wday - (timeptr->tm_yday % 7); if (jan1day < 0) jan1day += 7; /* * If Jan 1 was a Monday through Thursday, it was in * week 1. Otherwise it was last year's week 53, which is * this year's week 0. * * What does that mean? * If Jan 1 was Monday, the week number is exactly right, it can * never be 0. * If it was Tuesday through Thursday, the weeknumber is one * less than it should be, so we add one. * Otherwise, Friday, Saturday or Sunday, the week number is * OK, but if it is 0, it needs to be 53. */ switch (jan1day) { case 1: /* Monday */ break; case 2: /* Tuesday */ case 3: /* Wednedsday */ case 4: /* Thursday */ weeknum++; break; case 5: /* Friday */ case 6: /* Saturday */ case 0: /* Sunday */ if (weeknum == 0) weeknum = 53; break; } return weeknum; } #endif /* weeknumber --- figure how many weeks into the year */ /* With thanks and tip of the hatlo to ado(a)elsie.nci.nih.gov */ #ifndef __STDC__ static int weeknumber(timeptr, firstweekday) const struct tm *timeptr; int firstweekday; #else static int weeknumber(const struct tm *timeptr, int firstweekday) #endif { int wday = timeptr->tm_wday; int ret; if (firstweekday == 1) { if (wday == 0) /* sunday */ wday = 6; else wday--; } ret = ((timeptr->tm_yday + 7 - wday) / 7); if (ret < 0) ret = 0; return ret; } #if 0 /* ADR --- I'm loathe to mess with ado's code ... */ Date: Wed, 24 Apr 91 20:54:08 MDT From: Michal Jaegermann <audfax!emory!vm.ucs.UAlberta.CA!NTOMCZAK> To: arnold(a)audiofax.com Hi Arnold, in a process of fixing of strftime() in libraries on Atari ST I grabbed some pieces of code from your own strftime. When doing that it came to mind that your weeknumber() function compiles a little bit nicer in the following form: /* * firstweekday is 0 if starting in Sunday, non-zero if in Monday */ { return (timeptr->tm_yday - timeptr->tm_wday + (firstweekday ? (timeptr->tm_wday ? 8 : 1) : 7)) / 7; } How nicer it depends on a compiler, of course, but always a tiny bit. Cheers, Michal ntomczak(a)vm.ucs.ualberta.ca #endif #ifdef TEST_STRFTIME /* * NAME: * tst * * SYNOPSIS: * tst * * DESCRIPTION: * "tst" is a test driver for the function "strftime". * * OPTIONS: * None. * * AUTHOR: * Karl Vogel * Control Data Systems, Inc. * vogelke(a)c-17igp.wpafb.af.mil * * BUGS: * None noticed yet. * * COMPILE: * cc -o tst -DTEST_STRFTIME strftime.c */ /* ADR: I reformatted this to my liking, and deleted some unneeded code. */ #ifndef NULL #include <stdio.h> #endif #include <sys/time.h> #include <string.h> #define MAXTIME 132 /* * Array of time formats. */ static char *array[] = { "(%%A) full weekday name, var length (Sunday..Saturday) %A", "(%%B) full month name, var length (January..December) %B", "(%%C) Century %C", "(%%D) date (%%m/%%d/%%y) %D", "(%%E) Locale extensions (ignored) %E", "(%%H) hour (24-hour clock, 00..23) %H", "(%%I) hour (12-hour clock, 01..12) %I", "(%%M) minute (00..59) %M", "(%%O) Locale extensions (ignored) %O", "(%%R) time, 24-hour (%%H:%%M) %R", "(%%S) second (00..61) %S", "(%%T) time, 24-hour (%%H:%%M:%%S) %T", "(%%U) week of year, Sunday as first day of week (00..53) %U", "(%%V) week of year according to ISO 8601 %V", "(%%W) week of year, Monday as first day of week (00..53) %W", "(%%X) appropriate locale time representation (%H:%M:%S) %X", "(%%Y) year with century (1970...) %Y", "(%%Z) timezone (EDT), or blank if timezone not determinable %Z", "(%%a) locale's abbreviated weekday name (Sun..Sat) %a", "(%%b) locale's abbreviated month name (Jan..Dec) %b", "(%%c) full date (Sat Nov 4 12:02:33 1989)%n%t%t%t %c", "(%%d) day of the month (01..31) %d", "(%%e) day of the month, blank-padded ( 1..31) %e", "(%%h) should be same as (%%b) %h", "(%%j) day of the year (001..366) %j", "(%%k) hour, 24-hour clock, blank pad ( 0..23) %k", "(%%l) hour, 12-hour clock, blank pad ( 0..12) %l", "(%%m) month (01..12) %m", "(%%p) locale's AM or PM based on 12-hour clock %p", "(%%r) time, 12-hour (same as %%I:%%M:%%S %%p) %r", "(%%u) ISO 8601: Weekday as decimal number [1 (Monday) - 7] %u", "(%%v) VAX date (dd-bbb-YYYY) %v", "(%%w) day of week (0..6, Sunday == 0) %w", "(%%x) appropriate locale date representation %x", "(%%y) last two digits of year (00..99) %y", (char *) NULL }; /* main routine. */ int main(argc, argv) int argc; char **argv; { long time(); char *next; char string[MAXTIME]; int k; int length; struct tm *tm; long clock; /* Call the function. */ clock = time((long *) 0); tm = localtime(&clock); for (k = 0; next = array[k]; k++) { length = strftime(string, MAXTIME, next, tm); printf("%s\n", string); } exit(0); } #endif /* TEST_STRFTIME */ EOF

1 0

Re: Standard for timezone handling with TZ
by ado Feb. 22, 1994

Feb. 22, 1994

Attached is my current best effort at dealing with "GMT" files in the time zone package. I'd very much welcome any feedback. --ado # @(#)etcetera 7.2 # All of these are set up just so people can "zic -l" to a timezone # that's right for their area, even if it doesn't have a name or DST rules # (half hour zones are too much to bother with -- when someone asks!) Zone GMT 0 - GMT Link GMT UTC Link GMT UCT Link GMT Universal Link GMT Greenwich Link GMT Zulu Link GMT GMT-0 Link GMT GMT+0 Link GMT GMT0 # We use POSIX-style signedness in the names and output, # internal-style signedness in the specifications. # These are shoved down into an "Etc" directory so we get a name change-- # in earlier incarnations, we had lines such as # Zone GMT-12 -12 - GMT-1200 # and do not want things to change quietly if someone accustomed to the old # way does a # zic -l GMT-12 Zone Etc/GMT-12 12 - GMT-12 Zone Etc/GMT-11 11 - GMT-11 Zone Etc/GMT-10 10 - GMT-10 Zone Etc/GMT-9 9 - GMT-9 Zone Etc/GMT-8 8 - GMT-8 Zone Etc/GMT-7 7 - GMT-7 Zone Etc/GMT-6 6 - GMT-6 Zone Etc/GMT-5 5 - GMT-5 Zone Etc/GMT-4 4 - GMT-4 Zone Etc/GMT-3 3 - GMT-3 Zone Etc/GMT-2 2 - GMT-2 Zone Etc/GMT-1 1 - GMT-1 Zone Etc/GMT+1 -1 - GMT+1 Zone Etc/GMT+2 -2 - GMT+2 Zone Etc/GMT+3 -3 - GMT+3 Zone Etc/GMT+4 -4 - GMT+4 Zone Etc/GMT+5 -5 - GMT+5 Zone Etc/GMT+6 -6 - GMT+6 Zone Etc/GMT+7 -7 - GMT+7 Zone Etc/GMT+8 -8 - GMT+8 Zone Etc/GMT+9 -9 - GMT+9 Zone Etc/GMT+10 -10 - GMT+10 Zone Etc/GMT+11 -11 - GMT+11 Zone Etc/GMT+12 -12 - GMT+12 Zone Etc/GMT+13 -13 - GMT+13 # GMT offset 12 hours with DST

2 1

Re: Standard for timezone handling with TZ
by ado Feb. 14, 1994

Feb. 14, 1994

> That's a bug in the Olson rules; they aren't compatible with Posix > 1003.1-1990. Thanks for pointing it out. Here's a conservative patch > to Olson's latest version which renames `GMT-4' to `GMT-0400' to avoid > the bug. > > Another possibility is simply to remove the GMT[-+]* rules, since their > sign is the opposite of the sign in the Posix TZ string, and this is confusing. My guess is it's best to keep some sort of GMT rules; as the etcetera file notes, # All of these are set up just so people can "zic -l" to a timezone # that's right for their area, even if it doesn't have a name or dst rules # (half hour zones are too much to bother with -- when someone asks!) and if you don't have the rules you can't do the "zic -l". (Whether there should be some mechanism to establish a rule-based rather than file-based time zone as local time is another question.) > *** etcetera 1992/04/23 17:34:35 7.1 > --- etcetera 1994/02/10 19:49:45 7.1.1.1 > *************** > *** 6,55 **** > > Zone GMT 0 - GMT > > ! Zone GMT-12 -12 - GMT-1200 > ! Zone GMT-11 -11 - GMT-1100 Is it better to render these as, for example, > Zone GMT 0 - GMT > > ! Zone GMT+1200 -12 - GMT+1200 > ! Zone GMT+1100 -11 - GMT+1100 Or, given Casper H. S. Dik's example... > SunOS 4: > % env TZ=GMT-4 date GMT-4 is a timezone file (Olson) > Thu Feb 10 04:29:42 GMT-0400 1994 > % env TZ=GMT-04 date But use POSIX rules here > Thu Feb 10 12:32:21 GMT 1994 ...does POSIX *require* that the above rules be written > Zone GMT 0 - GMT > > ! Zone GMT+1200 -12 - GMT > ! Zone GMT+1100 -11 - GMT (that is, without the "+1200" modifier to the zone name that will appear in user-visible output)? --ado

3 2

Re: Standard for timezone handling with TZ
by eggert＠twinsun.com Feb. 10, 1994

Feb. 10, 1994

In comp.unix.solaris Casper H.S. Dik writes: > SunOS 4: > % env TZ=GMT-4 date GMT-4 is a timezone file (Olson) > Thu Feb 10 04:29:42 GMT-0400 1994 > % env TZ=GMT-04 date But use POSIX rules here > Thu Feb 10 12:32:21 GMT 1994 That's a bug in the Olson rules; they aren't compatible with Posix 1003.1-1990. Thanks for pointing it out. Here's a conservative patch to Olson's latest version which renames `GMT-4' to `GMT-0400' to avoid the bug. Another possibility is simply to remove the GMT[-+]* rules, since their sign is the opposite of the sign in the Posix TZ string, and this is confusing. *** etcetera 1992/04/23 17:34:35 7.1 --- etcetera 1994/02/10 19:49:45 7.1.1.1 *************** *** 6,55 **** Zone GMT 0 - GMT ! Zone GMT-12 -12 - GMT-1200 ! Zone GMT-11 -11 - GMT-1100 ! Zone GMT-10 -10 - GMT-1000 ! Zone GMT-9 -9 - GMT-0900 ! Zone GMT-8 -8 - GMT-0800 ! Zone GMT-7 -7 - GMT-0700 ! Zone GMT-6 -6 - GMT-0600 ! Zone GMT-5 -5 - GMT-0500 ! Zone GMT-4 -4 - GMT-0400 ! Zone GMT-3 -3 - GMT-0300 ! Zone GMT-2 -2 - GMT-0200 ! Zone GMT-1 -1 - GMT-0100 ! Zone GMT+1 1 - GMT+0100 ! Zone GMT+2 2 - GMT+0200 ! Zone GMT+3 3 - GMT+0300 ! Zone GMT+4 4 - GMT+0400 ! Zone GMT+5 5 - GMT+0500 ! Zone GMT+6 6 - GMT+0600 ! Zone GMT+7 7 - GMT+0700 ! Zone GMT+8 8 - GMT+0800 ! Zone GMT+9 9 - GMT+0900 ! Zone GMT+10 10 - GMT+1000 ! Zone GMT+11 11 - GMT+1100 ! Zone GMT+12 12 - GMT+1200 ! Zone GMT+13 13 - GMT+1300 # GMT+12 with DST Link GMT UTC Link GMT UCT Link GMT Universal Link GMT Greenwich Link GMT Zulu ! Link GMT GMT-0 ! Link GMT GMT+0 ! Link GMT GMT0 ! Link GMT+1 GMT1 ! Link GMT+2 GMT2 ! Link GMT+3 GMT3 ! Link GMT+4 GMT4 ! Link GMT+5 GMT5 ! Link GMT+6 GMT6 ! Link GMT+7 GMT7 ! Link GMT+8 GMT8 ! Link GMT+9 GMT9 ! Link GMT+10 GMT10 ! Link GMT+11 GMT11 ! Link GMT+12 GMT12 ! Link GMT+13 GMT13 --- 6,41 ---- Zone GMT 0 - GMT ! Zone GMT-1200 -12 - GMT-1200 ! Zone GMT-1100 -11 - GMT-1100 ! Zone GMT-1000 -10 - GMT-1000 ! Zone GMT-0900 -9 - GMT-0900 ! Zone GMT-0800 -8 - GMT-0800 ! Zone GMT-0700 -7 - GMT-0700 ! Zone GMT-0600 -6 - GMT-0600 ! Zone GMT-0500 -5 - GMT-0500 ! Zone GMT-0400 -4 - GMT-0400 ! Zone GMT-0300 -3 - GMT-0300 ! Zone GMT-0200 -2 - GMT-0200 ! Zone GMT-0100 -1 - GMT-0100 ! Zone GMT+0100 1 - GMT+0100 ! Zone GMT+0200 2 - GMT+0200 ! Zone GMT+0300 3 - GMT+0300 ! Zone GMT+0400 4 - GMT+0400 ! Zone GMT+0500 5 - GMT+0500 ! Zone GMT+0600 6 - GMT+0600 ! Zone GMT+0700 7 - GMT+0700 ! Zone GMT+0800 8 - GMT+0800 ! Zone GMT+0900 9 - GMT+0900 ! Zone GMT+1000 10 - GMT+1000 ! Zone GMT+1100 11 - GMT+1100 ! Zone GMT+1200 12 - GMT+1200 ! Zone GMT+1300 13 - GMT+1300 # GMT+12 with DST Link GMT UTC Link GMT UCT Link GMT Universal Link GMT Greenwich Link GMT Zulu ! Link GMT GMT-0000 ! Link GMT GMT+0000

1 0

Re: zic.c:mkdirs broken
by ado Feb. 10, 1994

Feb. 10, 1994

> The fix I sent before for this never made it into 94b. I don't know how > this fails to break everyone else. mkdirs is broken unless you compile > with -fwritable-strings (which is generally losing to do). > ... Thanks for the fix; it (and only it) is incorporated into tzcode94c.tar.gz on elsie.nci.nih.gov. The relevant diff is attached below. --ado SCCS/s.zic.c: 7.21 vs. 7.22 *** 7.21/zic.c Thu Feb 10 08:54:03 1994 --- 7.22/zic.c Thu Feb 10 08:54:04 1994 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.21"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.22"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1878,1890 **** } static int ! mkdirs(name) ! char * const name; { register char * cp; ! if ((cp = name) == NULL || *cp == '\0') return 0; while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix --- 1878,1892 ---- } static int ! mkdirs(argname) ! char * const argname; { + register char * name; register char * cp; ! if (argname == NULL || *argname == '\0') return 0; + cp = name = ecpyalloc(argname); while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix *************** *** 1906,1916 **** --- 1908,1920 ---- "%s: Can't create directory ", progname); (void) perror(name); + ifree(name); return -1; } } *cp = '/'; } + ifree(name); return 0; }

1 0

Re: zic.c:mkdirs broken
by Bradley White Feb. 9, 1994

Feb. 9, 1994

+ /* We must make a copy in case the + passed pointer is a read-only string. */ + char *name = ecpyalloc (argname); + if ((cp = name) == NULL || *cp == '\0') { + free (name); + return 0; + } ecpyalloc(x) [a.k.a. memcheck(icpyalloc(x))] cannot return 0. But, if you just want to program defensively, it is also good practice not to pass 0 to free(), despite what any standards might say. With the ialloc package you can achieve this via ifree(). Bradley

1 0

zic.c:mkdirs broken
by roland＠gnu.ai.mit.edu Feb. 9, 1994

Feb. 9, 1994

The fix I sent before for this never made it into 94b. I don't know how this fails to break everyone else. mkdirs is broken unless you compile with -fwritable-strings (which is generally losing to do). diff -u /home/gd3/roland/libc/time/zic.c.\~4\~ /home/gd3/roland/libc/time/zic.c --- /home/gd3/roland/libc/time/zic.c.~4~ Mon Feb 7 14:30:53 1994 +++ /home/gd3/roland/libc/time/zic.c Wed Feb 9 14:09:11 1994 @@ -1877,14 +1877,20 @@ charcnt += eitol(i); } + static int -mkdirs(name) -char * const name; +mkdirs(argname) +char * const argname; { register char * cp; + /* We must make a copy in case the + passed pointer is a read-only string. */ + char *name = ecpyalloc (argname); - if ((cp = name) == NULL || *cp == '\0') - return 0; + if ((cp = name) == NULL || *cp == '\0') { + free (name); + return 0; + } while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; #ifndef unix @@ -1906,11 +1912,13 @@ "%s: Can't create directory ", progname); (void) perror(name); + free (name); return -1; } } *cp = '/'; } + free (name); return 0; } Diff exited abnormally with code 1 at Wed Feb 9 14:09:45

1 0

leap seconds [forwarded with permission from wollman@uvm-gen.emba.uvm.edu]
by ado Feb. 7, 1994

Feb. 7, 1994

> From wollman(a)uvm-gen.EMBA.UVM.EDU Sun Feb 6 17:45:52 1994 > Return-Path: <wollman(a)uvm-gen.EMBA.UVM.EDU> > Received: from bajoran.emba.uvm.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA18437; Sun, 6 Feb 94 17:45:51 EST > Received: by bajoran.emba.uvm.edu id AA18471 > (5.65/6.05); Sun, 6 Feb 94 17:45:50 -0500 > Date: Sun, 6 Feb 94 17:45:50 -0500 > From: wollman(a)uvm-gen.EMBA.UVM.EDU > Message-Id: <9402062245.AA18471(a)bajoran.emba.uvm.edu> > To: ado(a)elsie.nci.nih.gov > Subject: Re: timezone servers > Newsgroups: comp.protocols.time.ntp > In-Reply-To: <1994Feb4.234532.26832(a)alw.nih.gov> > References: <199402020109.AA01671(a)ni.umd.edu> > Organization: University of Vermont, EMBA Computer Facility > > ...According to the bulletins that I've seen, |TAI-UTC| is about > 28 seconds now. However, the leapseconds file only lists 19 steps. > This is probably due to the fact that the first step was 10 seconds, > not just 1. Is there an easy way to fix this, so my users who use NTP > don't complain about their clocks being nine seconds off? > > -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. > NB: Address soon to | It is a bond more powerful than absence. We like people > be changed. | who like Shashish. - Claude McKenzie + Florent Vollant

4 3

tzcode94b.tar.gz and tzdata94b.tar.gz
by ado Feb. 7, 1994

Feb. 7, 1994

Updated time zone code and data is available by anonymous ftp from elsie.nci.nih.gov (128.231.16.1) in the "pub" directory; the culprits are -rw-r--r-- 1 ado 62145 Feb 7 10:04 tzcode94b.tar.gz -rw-r--r-- 1 ado 63993 Feb 7 10:04 tzdata94b.tar.gz The updates are the work by Paul Eggert (eggert(a)twinsun.com) who notes: > I found another book of time zone histories by E W Whitman; it's not as > extensive as Shanks but has a few goodies of its own. I used it to > update the tables. I also fixed some more as a result of > correspondence with Adam David and Peter Ilieve, and move some stray > links from `europe' to `backward'. I corrected some scanning errors in > usno1989. > > As far as the code goes, I fixed zic to allow years in the range > INT_MIN to INT_MAX; this fixed a few boundary conditions around 1900. > And I cleaned up the zic documentation a little bit. --ado

1 0

tzdata94a.tar.gz
by ado Feb. 3, 1994

Feb. 3, 1994

tzdata94a.tar.gz is now available on elsie.nci.nih.gov; it simply incorporates the recently announced leap second into the "leapseconds" file. For those who want to forego a trip to the ftp well, a diff from the previous version is attached. --ado SCCS/s.leapseconds: 7.6 vs. 7.7 *** 7.6/leapseconds Thu Feb 3 09:02:22 1994 --- 7.7/leapseconds Thu Feb 3 09:02:22 1994 *************** *** 1,4 **** ! # @(#)leapseconds 7.6 # Allowance for leapseconds added to each timezone file. --- 1,4 ---- ! # @(#)leapseconds 7.7 # Allowance for leapseconds added to each timezone file. *************** *** 38,40 **** --- 38,41 ---- Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S + Leap 1994 Jun 30 23:59:60 + S

1 0

time zones [forwarded with permission]
by ado Jan. 5, 1994

Jan. 5, 1994

> From ncm(a)netcom.com Wed Jan 5 03:20:09 1994 > Return-Path: <ncm(a)netcom.com> > Received: from mail.netcom.com (netcom3.netcom.com) by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA17468; Wed, 5 Jan 94 03:20:07 EST > Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) > id AAA02279; Wed, 5 Jan 1994 00:20:40 -0800 > Date: Wed, 5 Jan 1994 00:20:40 -0800 > From: ncm(a)netcom.com (Nathan Myers) > Message-Id: <199401050820.AAA02279(a)mail.netcom.com> > To: ado(a)elsie.nci.nih.gov > Subject: time zones > Status: RO > > Hello, > > I have been working on time zones at Rogue Wave Software, and > on locale support for the ISO/ANSI C++ Standard Library committee. > It seems to me that the C++ Library effort offers an excellent > place to standardize on a time zone library, as the contents > of a class timezone. We are not bound to C Library facilities > or conventions, so this is an opportunity to correct old mistakes. > (e.g. hidden static variables implied by the interface) > > Please forward this to anyone you think might be interested in > helping put together a proposal. > > Thank you > Nathan Myersn > myersn(a)roguewave.com

1 0

Re: Iceland's timezone
by Adam David Dec. 9, 1993

Dec. 9, 1993

> # time the norsemen first settled Iceland. The first day of winter is always > # Saturday, but is not dependent on the Julian or Gregorian calendars. I will try and find a general rule for this, but it may take awhile. > # We go with the Almanak, except for two claims from Shanks: > # 1. In 1968 standard time wasn't switched to GMT until Oct 27; > # this affects only the time zone name and dst flag. I wonder if this one is such a good idea. Here is the actual quote from the almanak (paraphrased): In the year 1968 "summer time" was finally made standard time in Iceland by law number 6 from April 5th that year. The change was made on April 7th at 2:00 GMT and the clock was adjusted forwards by one hour. Clock time in Iceland has since then been on GMT the whole year round. Of course, both Shanks and the Almanak have the same actual time offset for summer 1968, but technically it is the Almanak that is correct. Shanks chooses October 27th as the transition time because that is when the end of the summer time would otherwise have been (by the previous general rule). -- Adam David <adam(a)veda.is>

1 0

Iceland's timezone
by yata!eggert＠twinsun.com Dec. 9, 1993

Dec. 9, 1993

Thanks for looking up the U of Iceland Almanak. Here's how I translated what you wrote into tzfile format; I'll include this in the next set of revisions that I propose to ado. # 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. # # (December 5, 1993): # This material is paraphrased from the 1988 edition of the University of # Iceland Almanak. # # From January 1st, 1908 the whole of Iceland was standardised at 1 hour # behind GMT. Previously, local mean solar time was used in different parts # of Iceland, the almanak had been based on Reykjavik mean solar time which # was 1 hour and 28 minutes behind GMT. # # "first day of winter" referred to [below] means the first day of the 26 weeks # of winter, according to the old icelandic calendar that dates back to the # time the norsemen first settled Iceland. The first day of winter is always # Saturday, but is not dependent on the Julian or Gregorian calendars. # # From Paul Eggert <eggert(a)twinsun.com> (December 9, 1993): # The Iceland Almanak, Shanks and Whitman disagree on many points. # We go with the Almanak, except for two claims from Shanks: # 1. In 1968 standard time wasn't switched to GMT until Oct 27; # this affects only the time zone name and dst flag. # 2. Reykavik was -1:28 from 1837 to 1908, local mean time before that. # # 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 19 23:00 1:00 D Rule Iceland 1917 only - Oct 21 1:00 0 S Rule Iceland 1918 only - Nov 16 1:00 0 S Rule Iceland 1939 only - Apr 29 23:00 1:00 D Rule Iceland 1939 only - Nov 29 2:00 0 S Rule Iceland 1940 only - Feb 25 2:00 1:00 D Rule Iceland 1940 only - Nov 3 2:00 0 S Rule Iceland 1941 only - Mar 2 1:00s 1:00 D Rule Iceland 1941 only - Nov 2 1:00s 0 S Rule Iceland 1942 only - Mar 8 1:00s 1:00 D Rule Iceland 1942 only - Oct 25 1:00s 0 S # 1943-1946 - first Sunday in March until first Sunday in winter Rule Iceland 1943 1946 - Mar Sun>=1 1:00s 1:00 D Rule Iceland 1943 1948 - Oct Sun>=22 1:00s 0 S # 1947-1967 - first Sunday in April until first Sunday in winter Rule Iceland 1947 1968 - Apr Sun>=1 1:00s 1:00 D # 1949 Oct transition delayed by 1 week Rule Iceland 1949 only - Oct 30 1:00s 0 S Rule Iceland 1950 1966 - Oct Sun>=22 1:00s 0 S Rule Iceland 1967 only - Oct 29 1:00s 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Reykjavik -1:27:24 - LMT 1837 -1:28 - RMT 1908 # Reykjavik Mean Time -1:00 Iceland I%sT 1968 Oct 27 1:00s 0:00 - GMT

1 0

Re: Iceland's timezone
by Adam David Dec. 6, 1993

Dec. 6, 1993

Sorry about the delay getting back with this information. > 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. In a way, there was a timezone change in 1968, where the summertime change was applied during the spring, and became the all-year-round time, and there have been no changes since then, not for DST or any other reason. When looking back to previous years when there was DST, icelanders tend to refer to the concept of "winter time", as the summer time had the same offset as the present all-year-round time. This is why I was led to believe that no timezone change had taken place in 1968. > 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. I have no details of any abbreviations, sorry. > # 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 I don't feel up to messing with this table and submitting a corrected version. Here I copy a list of periods when summertime was active, and explanatory text. This material is paraphrased from the 1988 edition of the University of Iceland Almanak. >From January 1st, 1908 the whole of Iceland was standardised at 1 hour behind GMT. Previously, local mean solar time was used in different parts of Iceland, the almanak had been based on Reykjavik mean solar time which was 1 hour and 28 minutes behind GMT. Summertime when it was applied was always by putting the clock an hour forward during the summer months, which made the clock time equal to GMT. The following list shows when this summertime was in force. The time of the clock change is specified in GMT. year from to ---- ---- -- 1908-1916 no summertime 1917 20.Feb. 0:00 21.Oct. 1:00 1918 20.Feb. 0:00 16.Nov. 1:00 1919-1938 no summertime 1939 30.Apr. 0:00 29.Nov. 2:00 1940 25.Feb. 3:00 3.Nov. 2:00 1941 2.Mar. 2:00 2.Nov. 2:00 1942 8.Mar. 2:00 25.Oct. 2:00 1943-1946 rule (first Sunday in March until first Sunday in winter) 1943 7.Mar. 2:00 24.Oct. 2:00 1944 5.Mar. 2:00 22.Oct. 2:00 1945 4.Mar. 2:00 28.Oct. 2:00 1946 3.Mar. 2:00 27.Oct. 2:00 1947-1967 rule (first Sunday in April until first Sunday in winter) 1947 6.Apr. 2:00 26.Oct. 2:00 1948 4.Apr. 2:00 24.Oct. 2:00 1949 3.Apr. 2:00 ******* 30.Oct. 2:00 (delayed by 1 week) 1950 2.Apr. 2:00 22.Oct. 2:00 1951 1.Apr. 2:00 28.Oct. 2:00 1952 6.Apr. 2:00 26.Oct. 2:00 1953 5.Apr. 2:00 25.Oct. 2:00 1954 4.Apr. 2:00 24.Oct. 2:00 1955 3.Apr. 2:00 23.Oct. 2:00 1956 1.Apr. 2:00 28.Oct. 2:00 1957 7.Apr. 2:00 27.Oct. 2:00 1958 6.Apr. 2:00 26.Oct. 2:00 1959 5.Apr. 2:00 25.Oct. 2:00 1960 3.Apr. 2:00 23.Oct. 2:00 1961 2.Apr. 2:00 22.Oct. 2:00 1962 1.Apr. 2:00 28.Oct. 2:00 1963 7.Apr. 2:00 27.Oct. 2:00 1964 5.Apr. 2:00 25.Oct. 2:00 1965 4.Apr. 2:00 24.Oct. 2:00 1966 3.Apr. 2:00 23.Oct. 2:00 1967 2.Apr. 2:00 29.Oct. 2:00 1968 7.Apr. 2:00 (actually GMT after this) "first day of winter" referred to above, means the first day of the 26 weeks of winter, according to the old icelandic calendar that dates back to the time the norsemen first settled Iceland. The first day of winter is always Saturday, but is not dependent on the Julian or Gregorian calendars. This is the reason for the discrepancy with October 1961. I can find out more exactly how to determine when it falls, if necessary. It is a pity I don't have that information handy, otherwise I could include it here. There are more serious discrepancies before 1941 which are not obviously explainable. What to do... (?) -- Adam David <adam(a)veda.is>

1 0

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

Re: Shank's International Atlas
by ado Oct. 20, 1993

Oct. 20, 1993

Some initial feedback. 1. The notion in the README file is that > Historical local time information has been included here not because it > is particularly useful, but rather to: > > * give an idea of the variety of local time rules that have > existed in the past and thus an idea of the variety that may be > expected in the future; > > * provide a test of the generality of the local time rule description > system. That being so, we'd want to be on the lookout for rare timekeeping changes and be sure to include them. 2. A pragmatic answer to how many zones to have for France is "as many as are needed to describe the present day zones." As you noted, though, doing even this at the country level yields lots of zones. 3. As a last resort, simply reporting UCT for a zone when it's doing something awkward is a possibility. --ado

1 0

Shanks's International Atlas [forwarded with permission from eggert@twinsun.com]
by ado Oct. 20, 1993

Oct. 20, 1993

> From twinsun!twinsun.com!eggert(a)CS.UCLA.EDU Tue Oct 19 15:08:13 1993 > Return-Path: <twinsun!twinsun.com!eggert(a)CS.UCLA.EDU> > ... > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9310191858.AA24533(a)spot.twinsun.com> > Date: 19 Oct 1993 11:58:24 -0700 > To: ado(a)elsie.nci.nih.gov > Subject: Shanks's International Atlas > ... > > In looking through Shanks's atlas I see a number of points that perhaps need > further thinking before I sit down and try to generate more tables. The main > point is that we need to decide what the limitations of the tz database should > be. I'd appreciate your advice on the following points, which are roughly in > decreasing order of seriousness. > > There are many, many tables. E.g. France has 153 tables; most of the variants > occurred during World War II, as the fortunes of war caused different > districts to switch between French and German time zone rules. Do we really > want a directory labeled `France' with 153 files in it, one per district? > Even coming up with the district names will be a chore, as Shanks merely gives > each table a number and, for each city, tells you which time table it uses. > > Even the number of countries would mean that the timezone database would be > very bushy at top level, with entries ranging from Afghanistan to Zimbabwe. > Perhaps some substructure is in order. At some point you mentioned using ISO > country codes? (But how many people know their country code?) > > The current code makes no provision for when a district changed from LMT to > standard time (e.g. 1914 Jan 1 in Albania). Strictly speaking, it's incorrect > to give times other than LMT before the switch. At least we should put in a > comment when LMT began, I suppose. But should there be some provision in the > code as well? I suppose it would be something like a suffix to the TZ value > which specifies the LMT offset when LMT is in effect, since you can't possibly > have a table for each LMT offset. > > I doubt whether the following points are worth worrying about in the code, > but perhaps there should be a commenting convention for documenting these > points. > > Some countries switched from the Gregorian to the Julian calendar in this > century; e.g. part of Bulgaria held out until 1920 Sept 17 (Gregorian). I > suppose this is too much for the TZ code to handle, but perhaps comments are > in order. > > The Soviet Union instituted a 5 day week in 1929, a 6 day week in 1932, and > reverted to a 7 day week in 1940. > > China changed from the Chinese calendar on 1912 Feb 12 (Gregorian); > Japan from the Japanese calendar on 1893 Jan 1 (Gregorian). > > There was a time before LMT, when people used apparent time, not mean time. > E.g. Paris switched from apparent time to LMT in 1816.

1 0

Re: Shank's International Atlas, with GB-Eire as a test case
by ado Oct. 15, 1993

Oct. 15, 1993

Paul Eggert's changes are now incorporated in the files tzcode93f.tar.Z and tzdata93f.tar.Z in the ~ftp/pub directory of elsie.nci.nih.gov (128.231.16.1). Thanks to Paul Eggert for the information! --ado

1 0

Shank's International Atlas, with GB-Eire as a test case
by eggert＠twinsun.com Oct. 15, 1993

Oct. 15, 1993

I just found the book Thomas G. Shanks The International Atlas (3rd ed) San Diego: ACS Publications, Inc. (1991) xx + 428 pp. ISBN 0-935127-16-X, $36, order phone: +1 800 888 9983 which lists detailed historical time zone data, plus latitude and longitude, for places all over the world. For example, for Germany it lists over 20 pages of data in fine print, of which one page contains seven different historical time zone regions and the complete history of all GMT offsets in each region since the 1890s (when Germany started using standard time). There's a separate atlas (which I don't have) for US time zone data. ACS Publications serves astrologers, who seem to be the folks who care most about historical time zone data. (You get a 20% discount on your second order if you tell them your sun sign!) To see if it was good stuff, I checked Shanks's book vs the tz1993d rules for Great Britain and Eire. In nearly every case where Shanks disagreed with tz1993d, it seems to me that Shanks is more likely to be correct. The discrepancies included the following: * transcription errors in 1916, 1923, and 1968, where the tz1993d data doesn't match Peter Ilieve's transcription of the UK Government paper "Summer Time: A Consultation Document". * Shanks says summer time began in 1924 in 13 April, which seems far more likely to be correct than Ilieve's 30 April, since 30 April 1924 was a Wednesday. * Shanks says Eire did not observe war time during World War II, which seems likely since Eire was neutral. He says that Eire stayed an hour ahead of GMT through the war, and then had its own summer time scheme until 1948 when it reverted to GB time. * Shanks says Eire was 25 minutes behind GMT until 1916, switched to 35 minutes ahead of GMT during summer 1916, and then switched the clocks twice (!) on the morning of 1 Oct 1916, first to 1 hour ahead of GMT, then (35 minutes later) to GMT. This is the only hard-to-believe part of Shanks's data, but it's just crazy enough to be true. That last bit exposed another zdump bug: if the clock changes more than once in the same 12-hour period it sometimes misses some of the changes. I doubt whether Shanks is infallible -- his data for Israel looks funny, and he doesn't agree with the stories I've heard about the Soviet Union in the 1930s -- but it does seem like a good source, at least for those parts of the world where horoscopes are popular. Here's a proposed patch. =================================================================== RCS file: RCS/zdump.c,v retrieving revision 7.7 retrieving revision 7.7.1.1 diff -c -r7.7 -r7.7.1.1 *** zdump.c 1993/09/06 01:21:19 7.7 --- zdump.c 1993/10/15 00:18:49 7.7.1.1 *************** *** 82,88 **** static char * abbr(); static long delta(); ! static void hunt(); static int longest; static char * progname; static void show(); --- 82,88 ---- static char * abbr(); static long delta(); ! static time_t hunt(); static int longest; static char * progname; static void show(); *************** *** 177,183 **** if (delta(&newtm, &tm) != (newt - t) || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), buf) != 0) { ! hunt(argv[i], t, newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); } --- 177,184 ---- if (delta(&newtm, &tm) != (newt - t) || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), buf) != 0) { ! newt = hunt(argv[i], t, newt); ! newtm = *localtime(&newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); } *************** *** 208,214 **** ; } ! static void hunt(name, lot, hit) char * name; time_t lot; --- 209,215 ---- ; } ! static time_t hunt(name, lot, hit) char * name; time_t lot; *************** *** 237,242 **** --- 238,244 ---- } show(name, lot, TRUE); show(name, hit, TRUE); + return hit; } /* =================================================================== RCS file: RCS/europe,v retrieving revision 7.5 retrieving revision 7.5.1.1 diff -c -r7.5 -r7.5.1.1 *** europe 1993/09/06 01:21:38 7.5 --- europe 1993/10/15 00:19:31 7.5.1.1 *************** *** 7,12 **** --- 7,16 ---- # ahead and edit the file (and please send any changes to # ado(a)ncifcrf.gov for general use in the future). + # A good source for time zone historical data outside the U.S. is + # Thomas G. Shanks, The International Atlas (3rd edition), + # San Diego: ACS Publications, Inc. (1991). + ############################################################################### # United Kingdom *************** *** 52,58 **** # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September ! # 1924 30 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # --- 56,62 ---- # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September ! # 1924 13 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # *************** *** 120,125 **** --- 124,139 ---- # # These dates agree with the ones from Whitaker's Almanac for 1960--87. . . + # From Paul Eggert (October 14, 1993) + # + # I changed the date `30 April 1924' to `13 April 1924' in the above table + # to fix what must be transcription error, since 30 April is not a Sunday, + # and Shanks gives 13 April which is a Sunday. + # + # The rules for Eire below are taken from Shanks, and reflect his claim that + # Eire changed the clock twice on 1 Oct 1916. I invented `IST' and `IDT' as + # abbreviations for Eire's standard and daylight time before 1 Oct 1916. + # From Arthur David Olson (January 19, 1989): # # A source at the British Information Office in New York avers that it's *************** *** 210,216 **** # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular ! Rule GB-Eire 1916 only - Mar 21 2:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 2:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 2:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 2:00s 0 GMT --- 224,230 ---- # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular ! Rule GB-Eire 1916 only - May 21 2:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 2:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 2:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 2:00s 0 GMT *************** *** 225,232 **** Rule GB-Eire 1922 only - Mar 26 2:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 2:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 2:00s 1:00 BST ! Rule GB-Eire 1923 only - Oct 16 2:00s 0 GMT ! Rule GB-Eire 1924 only - Apr 30 2:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 2:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 2:00s 1:00 BST --- 239,246 ---- Rule GB-Eire 1922 only - Mar 26 2:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 2:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 2:00s 1:00 BST ! Rule GB-Eire 1923 only - Sep 16 2:00s 0 GMT ! Rule GB-Eire 1924 only - Apr 13 2:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 2:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 2:00s 1:00 BST *************** *** 266,272 **** Rule GB-Eire 1960 only - Apr 10 2:00s 1:00 BST Rule GB-Eire 1961 1963 - Mar lastSun 2:00s 1:00 BST Rule GB-Eire 1964 1967 - Mar Sun>=19 2:00s 1:00 BST - Rule GB-Eire 1968 only - Feb 18 2:00s 1:00 BST Rule GB-Eire 1972 1980 - Mar Sun>=16 2:00s 1:00 BST # 1953 to 1980, ending rules Rule GB-Eire 1953 1960 - Oct Sun>=1 2:00s 0 GMT --- 280,285 ---- *************** *** 278,284 **** Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone GB-Eire 0:00 GB-Eire %s 1968 Oct 27 2:00s 1:00 - BST 1971 Oct 31 2:00s 0:00 GB-Eire %s --- 291,309 ---- Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone GB 0:00 - GMT 1916 May 21 2:00s ! 0:00 GB-Eire %s 1968 Feb 18 2:00s ! 1:00 - BST 1971 Oct 31 2:00s ! 0:00 GB-Eire %s ! Zone Eire -0:25 - IST 1916 May 21 2:00 ! -0:25 1:00 IDT 1916 Oct 1 2:00 ! 0:00 1:00 BST 1916 Oct 1 3:00 ! 0:00 GB-Eire %s 1940 Feb 25 2:00 ! 0:00 1:00 BST 1946 Oct 6 2:00 ! 0:00 - GMT 1947 Mar 16 2:00 ! 0:00 1:00 BST 1947 Nov 2 2:00 ! 0:00 - GMT 1948 Apr 18 2:00 ! 0:00 GB-Eire %s 1968 Feb 18 2:00s 1:00 - BST 1971 Oct 31 2:00s 0:00 GB-Eire %s

1 0

Timezone info on BSDI Date & Time gateway
by bostic＠vangogh.CS.Berkeley.EDU Oct. 6, 1993

Oct. 6, 1993

>From sanders(a)BSDI.COM Tue Oct 5 19:42:36 1993 To: eng(a)BSDI.COM Subject: I knew this internet connection was good for something... Date: Tue, 05 Oct 1993 18:43:48 -0500 From: Tony Sanders <sanders(a)BSDI.COM> ------- Forwarded Message Received: from probitas.cs.utas.edu.au by austin.BSDI.COM (5.67/1.37) id AA09594; Tue, 5 Oct 93 18:21:17 -0500 Received: from brian.cs.utas.edu.au by probitas.cs.utas.edu.au (AIX 3.2/UCB 5.64/4.03) id AA41183; Wed, 6 Oct 1993 10:21:41 +1000 Message-Id: <9310060021.AA41183(a)probitas.cs.utas.edu.au> X-Sender: brian(a)probitas.cs.utas.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Oct 1993 10:21:10 +1000 To: sanders(a)www.bsdi.com From: Brian.Marriott(a)probitas.cs.utas.edu.au (Brian Marriott) Subject: Timezone info on BSDI Date & Time gateway Hi Tony I just had occasion to check the BSDI Date & Time gateway via www. Congratulations, it looks good - a great idea. You've got one minor thing wrong in your timezone info, though (through no fault of yours). The timezone for Tasmania, Australia shows currently as GMT+10, but it's actually at GMT+11. A recent bureaucratic decision means that Tasmania switches to daylight saving (GMT+11) on the first Sunday in October (at 0200, GMT+10), and switches back to Eastern Australian Standard Time (GMT+10) on the last Sunday in March (at 0200, GMT+11). You can't be expected to be aware of this, I know, because it was only recently announced here in Tasmania. Cheers, Brian Marriott (a non-animated Tasmanian Devil) - ------------------------------------------------------------- Brian Marriott AARNet: Brian.Marriott(a)cs.utas.edu.au Department of Computer Science University of Tasmania Phone: 002 202 929 Fax: 002 202 913 (Int'l +61 02 202 913) Postal address: GPO Box 252C, Hobart Tasmania 7001, Australia ------- End of Forwarded Message

1 0

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

Sept. 6, 1993

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

1 0

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

Sept. 5, 1993

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

1 0

Re: Kwajalein bug fix
by ado Aug. 28, 1993

Aug. 28, 1993

Thanks to Paul Eggert for the Kwajalein changes. My notions on how to do it are attached. It might be better to toss Kwajalein into australasia than to create a new file; as I recall, some vendors might be using a "patch" scheme that's better at handling changes than handling additions. I also took the opportunity while visiting zdump to eliminate the "VERY approximate" kludge in handling zdump's "-c" option. (Given the relentless increase in processor power, maybe the better thing to do is eliminate the "-c" option.) I'll wait a bit for feedback from this list; eventually folks should expect to see tzcode93e.tar.Z and tzdata93e.tar.Z on elsie.nci.nih.gov. --ado SCCS/s.australasia: 7.13 vs. 7.14 *** 7.13/australasia Sat Aug 28 12:29:52 1993 --- 7.14/australasia Sat Aug 28 12:29:52 1993 *************** *** 1,4 **** ! # @(#)australasia 7.13 # Notes are at the end of this file --- 1,4 ---- ! # @(#)australasia 7.14 # Notes are at the end of this file *************** *** 105,110 **** --- 105,118 ---- ############################################################################### + # Kwajalein + + # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] + Zone Kwajalein -12:00 - KST 1993 Aug 20 + 12:00 - KST + + ############################################################################### + # NOTES ############################################################################### *************** *** 431,433 **** --- 439,451 ---- # From Arthur David Olson (March 8, 1992): # The chosen rules use the Davies October 8 values for the start of DST in 1989 # rather than the October 1 value. + + ############################################################################### + + # Kwajalein + + # In comp.risks 14.87 (26 August 1993), Peter Neumann writes: + # I wonder what happened in Kwajalein, where there was NO Friday, + # August 20, 1993. Thursday night at midnight Kwajalein switched sides with + # respect to the International Date Line, to rejoin its fellow islands, + # going from 11:59 p.m. Thursday to 12:00 m. Saturday in a blink. SCCS/s.zdump.c: 7.3 vs. 7.5 *** 7.3/zdump.c Sat Aug 28 12:30:03 1993 --- 7.5/zdump.c Sat Aug 28 12:30:03 1993 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zdump.c 7.3"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zdump.c 7.5"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 39,46 **** #define SECSPERMIN 60 #endif /* !defined SECSPERMIN */ #ifndef SECSPERHOUR ! #define SECSPERHOUR 3600 #endif /* !defined SECSPERHOUR */ #ifndef HOURSPERDAY --- 39,50 ---- #define SECSPERMIN 60 #endif /* !defined SECSPERMIN */ + #ifndef MINSPERHOUR + #define MINSPERHOUR 60 + #endif /* !defined MINSPERHOUR */ + #ifndef SECSPERHOUR ! #define SECSPERHOUR (SECSPERMIN * MINSPERHOUR) #endif /* !defined SECSPERHOUR */ #ifndef HOURSPERDAY *************** *** 51,60 **** --- 55,72 ---- #define EPOCH_YEAR 1970 #endif /* !defined EPOCH_YEAR */ + #ifndef TM_YEAR_BASE + #define TM_YEAR_BASE 1900 + #endif /* !defined TM_YEAR_BASE */ + #ifndef DAYSPERNYEAR #define DAYSPERNYEAR 365 #endif /* !defined DAYSPERNYEAR */ + #ifndef isleap + #define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0) + #endif /* !defined isleap */ + extern char ** environ; extern int getopt(); extern char * optarg; *************** *** 104,116 **** argv[0], argv[0]); (void) exit(EXIT_FAILURE); } ! if (cutoff != NULL) cutyear = atoi(cutoff); ! /* ! ** VERY approximate. ! */ ! cuttime = (long) (cutyear - EPOCH_YEAR) * ! SECSPERHOUR * HOURSPERDAY * DAYSPERNYEAR; (void) time(&now); longest = 0; for (i = optind; i < argc; ++i) --- 116,130 ---- argv[0], argv[0]); (void) exit(EXIT_FAILURE); } ! if (cutoff != NULL) { ! int y; ! cutyear = atoi(cutoff); ! cuttime = 0; ! for (y = EPOCH_YEAR; y < cutyear; ++y) ! cuttime += DAYSPERNYEAR + isleap(y); ! cuttime *= SECSPERHOUR * HOURSPERDAY; ! } (void) time(&now); longest = 0; for (i = optind; i < argc; ++i) *************** *** 231,243 **** struct tm * oldp; { long result; ! result = newp->tm_hour - oldp->tm_hour; ! if (result < 0) ! result += HOURSPERDAY; ! result *= SECSPERHOUR; ! result += (newp->tm_min - oldp->tm_min) * SECSPERMIN; ! return result + newp->tm_sec - oldp->tm_sec; } static void --- 245,265 ---- struct tm * oldp; { long result; + int tmy; ! if (newp->tm_year < oldp->tm_year) ! return -delta(oldp, newp); ! result = 0; ! for (tmy = oldp->tm_year; tmy < newp->tm_year; ++tmy) ! result += DAYSPERNYEAR + isleap(tmy + TM_YEAR_BASE); ! result += newp->tm_yday - oldp->tm_yday; ! result *= HOURSPERDAY; ! result += newp->tm_hour - oldp->tm_hour; ! result *= MINSPERHOUR; ! result += newp->tm_min - oldp->tm_min; ! result *= SECSPERMIN; ! result += newp->tm_sec - oldp->tm_sec; ! return result; } static void

1 0

Kwajalein bug fix
by eggert＠stet.twinsun.com Aug. 26, 1993

Aug. 26, 1993

Kwajalein's missing day uncovered a bug in zdump.c, which missed the 24-hour jump ahead because the jump was masked by the HOURSPERDAY hack in the `delta' function. Here's a patch, plus a proposed new `pacific' file for islands in the Pacific. I've made up the abbreviation `KST'; I don't know what abbreviation Kwajaleinians really use. I don't know when Kwajalein originally started using -12:00 -- it must have been soon after WW II. *** /dev/null Fri Aug 27 07:48:01 1993 --- pacific Fri Aug 27 07:38:41 1993 *************** *** 0 **** --- 1,14 ---- + # @(#)pacific + + + # Kwajalein + + # In comp.risks 14.87 (26 August 1993), Peter Neumann writes: + # I wonder what happened in Kwajalein, where there was NO Friday, + # August 20, 1993. Thursday night at midnight Kwajalein switched sides with + # respect to the International Date Line, to rejoin its fellow islands, + # going from 11:59 p.m. Thursday to 12:00 m. Saturday in a blink. + + # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] + Zone Kwajalein -12:00 - KST 1993 Aug 20 + 12:00 - KST =================================================================== RCS file: zdump.c,v retrieving revision 7.3 retrieving revision 7.3.1.1 diff -c -r7.3 -r7.3.1.1 *** zdump.c 1993/01/08 12:00:38 7.3 --- zdump.c 1993/08/26 21:08:10 7.3.1.1 *************** *** 55,60 **** --- 55,64 ---- #define DAYSPERNYEAR 365 #endif /* !defined DAYSPERNYEAR */ + #ifndef TM_YEAR_BASE + #define TM_YEAR_BASE 1900 + #endif + extern char ** environ; extern int getopt(); extern char * optarg; *************** *** 230,243 **** struct tm * newp; struct tm * oldp; { ! long result; ! ! result = newp->tm_hour - oldp->tm_hour; ! if (result < 0) ! result += HOURSPERDAY; ! result *= SECSPERHOUR; ! result += (newp->tm_min - oldp->tm_min) * SECSPERMIN; ! return result + newp->tm_sec - oldp->tm_sec; } static void --- 234,256 ---- struct tm * newp; struct tm * oldp; { ! int newy = newp->tm_year + (TM_YEAR_BASE - 1); ! int oldy = oldp->tm_year + (TM_YEAR_BASE - 1); ! return ! ( ! ( ! ( ! /* difference in day of year */ ! newp->tm_yday - oldp->tm_yday ! /* + intervening leap days */ ! + (newy/4 - oldy/4) ! - (newy/100 - oldy/100) ! + (newy/400 - oldy/400) ! /* + difference in years * 365 */ ! + (long)(newy-oldy) * 365 ! )*24 + (newp->tm_hour - oldp->tm_hour) ! )*60 + (newp->tm_min - oldp->tm_min) ! )*60 + (newp->tm_sec - oldp->tm_sec); } static void

1 0

Item forwarded from comp.protocols.time.ntp
by ado Aug. 26, 1993

Aug. 26, 1993

> From bob(a)kahala.soest.hawaii.edu Mon Aug 23 17:07:53 1993 > Path: nih-csl!darwin.sura.net!howland.reston.ans.net!agate!ames!news.Hawaii.Edu!kahala!bob > From: bob(a)kahala.soest.hawaii.edu (Bob Cunningham) > Newsgroups: comp.protocols.time.ntp > Subject: time trivia, Kwajelein skips a day > Message-ID: <CC8DD5.7It(a)news.Hawaii.Edu> > Date: 23 Aug 93 21:07:53 GMT > Sender: news(a)news.Hawaii.Edu > Organization: School of Ocean and Earth Science and Technology > Lines: 18 > Originator: bob@kahala > > Everyone living on the remote Pacific atoll of Kwajelein in the > Marshall Islands will have a good excuse for not remembering last > Saturdy night. There wasn't one. Residents went to bed on Friday and > woke up on Sunday. There was no 21st of August. The government just > changed Kwajelein to Marshallese time, effectively jumping the island > from one side of the International Date Line to the far side (where it > actually is, the IDL being 300 miles to east of Kwaj). The US Army has > for the last 40 years been synchronizing the day of the week for its > workers on Kwaj with the US mainland. > > But most workers didn't lose a day off. The work week was shifted to > Tuesday through Saturday, corresponding with Monday through Friday on > the mainland. > > -- > Bob Cunningham > bob(a)soest.hawaii.edu > School of Ocean & Earth Science & Technology, University of Hawaii

1 0

Is leap second support working in the latest time zone code?
by eggert＠twinsun.com July 9, 1993

July 9, 1993

With the latest time zone code I tried `zdump -v right/US/Pacific' and got the following output. This looks wrong to me -- the times labeled `GMT' are actually International Atomic Time (TAI), not Coordinated Universal Time (UTC). zdump uses gmtime to print the GMT part. But even with leap second support, gmtime should yield UTC, not TAI, at least according to ANSI C X3.159-1989 section 4.12.3.3. Or am I missing something here? right/US/Pacific Sun Apr 4 10:00:16 1993 GMT = Sun Apr 4 01:59:59 1993 PST isdst=0 right/US/Pacific Sun Apr 4 10:00:17 1993 GMT = Sun Apr 4 03:00:00 1993 PDT isdst=1 right/US/Pacific Thu Jul 1 00:00:17 1993 GMT = Wed Jun 30 16:59:60 1993 PDT isdst=1 right/US/Pacific Thu Jul 1 00:00:18 1993 GMT = Wed Jun 30 17:00:00 1993 PDT isdst=1 right/US/Pacific Sun Oct 31 09:00:17 1993 GMT = Sun Oct 31 01:59:59 1993 PDT isdst=1 right/US/Pacific Sun Oct 31 09:00:18 1993 GMT = Sun Oct 31 01:00:00 1993 PST isdst=0

2 1

Solaris 2.2 has many timezone bugs
by eggert＠shadow.twinsun.com June 22, 1993

June 22, 1993

Solaris 2.2 seems based on a particularly ancient version of the timezone code. It has many bugs that, near as I can tell, were fixed as long ago as 1989 in the public domain version. This is a real step backwards from SunOS 4.1.x. The most serious bug will occur on October 24, 1993 in GB-Eire: Solaris 2.2's switch from summer to winter time will be delayed until October 31. There are some other bugs in Australia, Brazil, Chile, Israel, and Korea zones. I just filed an official bug report with Sun, but I don't have much hope of it having an effect in time. Perhaps someone with some influence at Sun can get them to upgrade to the latest tz code before Solaris 2.3 comes out. Or I could just post a note to comp.risks...

1 0

Julian date conversion code
by jim＠bilbo.suite.com June 19, 1993

June 19, 1993

Does anyone know where I can find some public domain code that converts Julian (and Modified Julian) Dates to "seconds since start of (UNIX/GMT)" and back? thanks, Jim-Miller(a)suite.com

1 0

Re: tz93c botches time zone transitions in Brazil
by ado June 18, 1993

June 18, 1993

Thanks for this new fix. Both it and the new data on Israel are now incorporated in ~ftp/pub/tzcode93d.tar.Z and ~ftp/pub/tzdata93d.tar.Z on elsie.nci.nih.gov (128.231.16.1). (And I think the woes of elsie's transition from being a Sun 3 to being a Sun 4 are over.) --ado

1 0

tz93c botches time zone transitions in Brazil
by eggert＠twinsun.com June 18, 1993

June 18, 1993

Ed Reingold noticed that SunOS 4.1.2 mishandles the time zone transitions in Brazil. Typically, it claims that the transitions occur on Friday, whereas the rule says they should occur on Saturday. The bug is still present in tz93c (the 1993-06-06 version of the time zone code). I looked into the problem, and discovered that zic botches any rule whose ON field is of the form `DAY<=N', where DAY is not Sunday, and where the Nth day of the current year is not DAY. In this case, it acts as if you specified the previous day to DAY. As it happens, the only rules of this form in the database are those of Brazil. For example if you run `zdump -v Brazil/East' you'll see that most of the transitions occur on Friday, but they're all supposed to occur on Saturday. Here is a patch to tz93c. I'm amazed that this bug has never been reported in all these years. Shall we chalk it up to Brazil's strict import restrictions on American software? =================================================================== RCS file: zic.c,v retrieving revision 7.8 retrieving revision 7.8.1.1 diff -c -r7.8 -r7.8.1.1 *** zic.c 1993/06/06 23:31:38 7.8 --- zic.c 1993/06/18 02:58:46 7.8.1.1 *************** *** 1819,1825 **** } else { dayoff = oadd(dayoff, (long) -1); if (--wday < 0) ! wday = LDAYSPERWEEK; --i; } if (i < 0 || i >= len_months[isleap(y)][m]) { --- 1819,1825 ---- } else { dayoff = oadd(dayoff, (long) -1); if (--wday < 0) ! wday = LDAYSPERWEEK - 1; --i; } if (i < 0 || i >= len_months[isleap(y)][m]) {

1 0

automated generation of the Zion rules
by eggert＠twinsun.com June 17, 1993

June 17, 1993

Here's a patch to the Zion rules that gives a program to generate the rules, plus the DST transitions for the years 2010 through 2037. =================================================================== RCS file: asia,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** asia 1992/04/23 17:34:49 1.1 --- asia 1993/06/17 00:04:53 1.2 *************** *** 119,124 **** --- 119,157 ---- # [**] actually Saturday night as the Jewish day commences at nightfall. # [***] the Jewish Lunar New Year. + # From Paul Eggert (June 16, 1993). Ed Reingold and I converted the above + # rules into the following Emacs lisp code. It requires GNU Emacs 19.13 + # or later. If you run the code, the Zion rules will be inserted into + # your Emacs buffer. Reference: ``Calendrical Calculations'' by Nachum + # Dershowitz and Edward M. Reingold, Software--Practice and Experience, + # Volume 20, Number 9 (September, 1990), pages 899-928. + # + # (calendar-for-loop + # year from 1989 to 2037 do + # (let ((dst-starts + # (calendar-gregorian-from-absolute + # (calendar-dayname-on-or-before + # 0 + # (calendar-absolute-from-hebrew + # (list 1 28 (+ year 3760)))))) + # (dst-ends + # (calendar-gregorian-from-absolute + # (calendar-dayname-on-or-before + # 0 + # (- (calendar-absolute-from-hebrew (list 7 1 (+ year 3761))) 3))))) + # (insert (format "Rule\tZion\t%d\tonly\t-\t%3s\t%2d\t0:00\t1:00\tD\n" + # year + # (substring + # (calendar-month-name (extract-calendar-month dst-starts)) + # 0 3) + # (extract-calendar-day dst-starts))) + # (insert (format "Rule\tZion\t%d\tonly\t-\t%3s\t%2d\t0:00\t0:00\tS\n" + # year + # (substring + # (calendar-month-name (extract-calendar-month dst-ends)) + # 0 3) + # (extract-calendar-day dst-ends))))) + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D Rule Zion 1989 only - Sep 24 0:00 0:00 S *************** *** 162,167 **** --- 195,256 ---- Rule Zion 2008 only - Sep 21 0:00 0:00 S Rule Zion 2009 only - Apr 19 0:00 1:00 D Rule Zion 2009 only - Sep 13 0:00 0:00 S + Rule Zion 2010 only - Apr 11 0:00 1:00 D + Rule Zion 2010 only - Sep 5 0:00 0:00 S + Rule Zion 2011 only - May 1 0:00 1:00 D + Rule Zion 2011 only - Sep 25 0:00 0:00 S + Rule Zion 2012 only - Apr 15 0:00 1:00 D + Rule Zion 2012 only - Sep 9 0:00 0:00 S + Rule Zion 2013 only - Apr 7 0:00 1:00 D + Rule Zion 2013 only - Sep 1 0:00 0:00 S + Rule Zion 2014 only - Apr 27 0:00 1:00 D + Rule Zion 2014 only - Sep 21 0:00 0:00 S + Rule Zion 2015 only - Apr 12 0:00 1:00 D + Rule Zion 2015 only - Sep 6 0:00 0:00 S + Rule Zion 2016 only - May 1 0:00 1:00 D + Rule Zion 2016 only - Sep 25 0:00 0:00 S + Rule Zion 2017 only - Apr 23 0:00 1:00 D + Rule Zion 2017 only - Sep 17 0:00 0:00 S + Rule Zion 2018 only - Apr 8 0:00 1:00 D + Rule Zion 2018 only - Sep 2 0:00 0:00 S + Rule Zion 2019 only - Apr 28 0:00 1:00 D + Rule Zion 2019 only - Sep 22 0:00 0:00 S + Rule Zion 2020 only - Apr 19 0:00 1:00 D + Rule Zion 2020 only - Sep 13 0:00 0:00 S + Rule Zion 2021 only - Apr 4 0:00 1:00 D + Rule Zion 2021 only - Aug 29 0:00 0:00 S + Rule Zion 2022 only - Apr 24 0:00 1:00 D + Rule Zion 2022 only - Sep 18 0:00 0:00 S + Rule Zion 2023 only - Apr 16 0:00 1:00 D + Rule Zion 2023 only - Sep 10 0:00 0:00 S + Rule Zion 2024 only - May 5 0:00 1:00 D + Rule Zion 2024 only - Sep 29 0:00 0:00 S + Rule Zion 2025 only - Apr 20 0:00 1:00 D + Rule Zion 2025 only - Sep 14 0:00 0:00 S + Rule Zion 2026 only - Apr 12 0:00 1:00 D + Rule Zion 2026 only - Sep 6 0:00 0:00 S + Rule Zion 2027 only - May 2 0:00 1:00 D + Rule Zion 2027 only - Sep 26 0:00 0:00 S + Rule Zion 2028 only - Apr 23 0:00 1:00 D + Rule Zion 2028 only - Sep 17 0:00 0:00 S + Rule Zion 2029 only - Apr 8 0:00 1:00 D + Rule Zion 2029 only - Sep 2 0:00 0:00 S + Rule Zion 2030 only - Apr 28 0:00 1:00 D + Rule Zion 2030 only - Sep 22 0:00 0:00 S + Rule Zion 2031 only - Apr 20 0:00 1:00 D + Rule Zion 2031 only - Sep 14 0:00 0:00 S + Rule Zion 2032 only - Apr 4 0:00 1:00 D + Rule Zion 2032 only - Aug 29 0:00 0:00 S + Rule Zion 2033 only - Apr 24 0:00 1:00 D + Rule Zion 2033 only - Sep 18 0:00 0:00 S + Rule Zion 2034 only - Apr 16 0:00 1:00 D + Rule Zion 2034 only - Sep 10 0:00 0:00 S + Rule Zion 2035 only - May 6 0:00 1:00 D + Rule Zion 2035 only - Sep 30 0:00 0:00 S + Rule Zion 2036 only - Apr 20 0:00 1:00 D + Rule Zion 2036 only - Sep 14 0:00 0:00 S + Rule Zion 2037 only - Apr 12 0:00 1:00 D + Rule Zion 2037 only - Sep 6 0:00 0:00 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 2:00 Zion I%sT

1 0

time zone survey
by ado June 11, 1993

June 11, 1993

Attached are results from a casual time zone survey. Last week I ran through the news articles on nih-csl.dcrt.nih.gov (the nntp newsfeed system for elsie.nci.nih.gov) getting the "Date: " and "Message-ID: " line from each article. Article file names were obtained from the news history file to ensure that any cross-posted articles would only be used once. I tossed out data with unzoned time stamps, data without a recognizable domained system name in the Message-ID, and data from ".com" sites. This left 17,912 date/name pairs. I massaged the data into the form... 05210205 (AEST) megalink.apana.org.au 05010053 +0000 compex.e-burg.su ...where the first field gives two digits each of month, day, hour, and minute from the Date, the second field gives the time zone that appeared in the Date, and the third field is the system name from the Message-ID. This data is available in the file ~ftp/pub/zonesurvey on elsie.nci.nih.gov (128.231.16.1). Eighty-nine different zones showed up (sorted alphabetically here): (AEST) +0000 +0001 +0100 +02 +0200 +0300 +0400 +0500 +0530 +0600 +0611 +0700 +0730 +0800 +0930 +1 +1000 +1100 +1200 +1300 +1700 -0000 -0100 -0300 -0400 -0500 -0520 -0600 -0700 -0800 -1 -1000 -1200 -600 ACST ADT AEST AET ARG AST BSC BST CDT CED CEST CET CST DST EDT EDZ EET EMT EST GMT GMT+01 GMT+0200 GMT+1 GMT+12 GMT+1200 GMT+2 IDT IST JST LCL MDT MED MES MEST MESZ MET MEWT MEZ MST NDT NZDT NZST PDT PST SGP TUR TZONE U UT WET WET+0100 WST XDT Y The number of times each zone showed up (sorted by number of times here): 3820 -0400 1925 EDT 1902 -0500 994 EST 919 -0700 913 CDT 748 +0000 690 +0200 664 CST 655 PDT 621 +0100 583 -0600 499 +1000 467 MDT 398 PST 275 +1200 211 BST 170 +0001 153 MET 138 -0800 135 MST 123 +0300 116 CET 98 +0800 97 -0300 53 +0400 51 +0930 45 -0100 36 +1300 35 WET 33 -0000 27 UT 23 ACST 22 MEZ 22 NZST 20 +1700 20 GMT+12 17 IDT 16 TUR 14 MESZ 9 +02 8 MEST 8 WET+0100 7 +0600 7 CED 7 CEST 7 LCL 6 AET 6 DST 6 EET 6 EMT 5 AST 5 GMT 5 GMT+01 5 GMT+0200 5 U 4 -1000 4 IST 3 +0700 3 +1100 3 -0520 3 -1200 3 -600 3 EDZ 3 TZONE 3 Y 2 ADT 2 ARG 2 BSC 2 GMT+1200 2 MED 2 MES 2 SGP 1 (AEST) 1 +0500 1 +0530 1 +0611 1 +0730 1 +1 1 -1 1 AEST 1 GMT+1 1 GMT+2 1 JST 1 MEWT 1 NDT 1 NZDT 1 WST 1 XDT Aside from the 51 "+0930" articles from Australia, only four "oddball" numeric time zones show up, and each of them only shows up from one system (the Date and system name from the original data are shown here): 3 -0520 Wed, 2 Jun 93 22:22:00 -0520 freddy.ampr.ab.ca Thu, 3 Jun 93 20:08:00 -0520 freddy.ampr.ab.ca Sat, 5 Jun 93 16:05:00 -0520 freddy.ampr.ab.ca 1 +0530 1 Jun 93 15:30:55 +0530 imtech.ernet.in 1 +0611 Wed, 02 Jun 93 16:08:33 +0611 trashcan.hacktic.nl 1 +0730 6 Jun 1993 08:25:56 +0730 news.Colorado.EDU Time zone abbrevations that show up in tzdata93c.tar.Z files: ADT Atlantic Daylight Time AST Atlantic Standard Time BST British Standard Time CDT Central Daylight Time CET Central European Time CST Central Standard Time EDT Eastern Daylight Time EET Eastern European Time EST Eastern Standard Time IDT Israeli Daylight Time IST Israeli Standard Time JST Japanese Standard Time MDT Mountain Daylight Time MET Middle European Time MST Mountain Standard Time NZDT New Zealand Daylight Time NZST New Zealand Standard Time PDT Pacific Daylight Time PST Pacific Standard Time WET Western European Time WST Western Standard Time Time zone abbreviations that are fairly clear are: (AEST) Australian Eastern Standard Time (used only by one system) Fri, 21 May 93 02:05:36 (AEST) megalink.apana.org.au ACST Australian Central Standard Time 21 May 93 13:18:16 ACST state.systems.sa.gov.au Tue, 25 May 93 13:27:42 ACST cola.pax.tpa.com.au ... 4 Jun 93 00:47:42 ACST state.systems.sa.gov.au Sun, 06 Jun 93 19:13:17 ACST cola.pax.tpa.com.au AEST Australian Eastern Standard Time Fri, 04 Jun 93 21:47:10 AEST ese.escape.brisnet.org.au AET Australian Eastern Time (used only by one system) 10 May 93 08:50:04 AET licre.ludwig.edu.au 27 May 93 19:00:11 AET licre.ludwig.edu.au 28 May 93 12:46:13 AET licre.ludwig.edu.au 1 Jun 93 08:46:51 AET licre.ludwig.edu.au 1 Jun 93 09:02:16 AET licre.ludwig.edu.au 7 Jun 93 14:52:39 AET licre.ludwig.edu.au CED Central European Daylight 28 Apr 93 21:00:06 CED alphanet.alphanet.ch 27 May 93 22:53:59 CED sourcery.han.de 28 May 93 18:36:06 CED sourcery.han.de 1 Jun 93 22:16:54 CED sourcery.han.de 1 Jun 93 22:22:52 CED sourcery.han.de 1 Jun 93 22:45:24 CED sourcery.han.de 2 Jun 93 21:05:10 CED sourcery.han.de CEST Central European Standard Time Tue, 25 May 93 07:26:34 CEST obula.nbg.sub.org Tue, 25 May 93 15:58:02 CEST obula.nbg.sub.org Wed, 26 May 93 12:46:27 CEST obula.nbg.sub.org Tue, 01 Jun 93 11:18:35 CEST obula.nbg.sub.org Wed, 02 Jun 93 08:42:25 CEST obula.nbg.sub.org Fri, 04 Jun 1993 17:45:26 CEST oktagon.rd.sub.org Sun, 06 Jun 93 20:44:27 CEST scrum.greenie.muc.de MED Middle European Daylight (used only by one system) 3 Jun 93 00:17:24 MED lifestyle.rhein-main.de 6 Jun 93 12:27:48 MED lifestyle.rhein-main.de MES Middle European Standard (used only by one system) Sat, 22 May 93 12:46:44 MES wolferts.ka.sub.org Sun, 06 Jun 93 15:05:50 MES wolferts.ka.sub.org MESZ Middle European Standard Zone Tue, 25 May 1993 17:49:06 MESZ email.tuwien.ac.at Wed, 26 May 1993 12:12:26 MESZ gwdu14.gwdg.de Wed, 26 May 93 14:03:58 MESZ lbl.gov Fri, 28 May 1993 00:02:42 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:03:34 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:04:26 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:12:50 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:13:56 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:15:10 MESZ nasim.sta.sub.org Sat, 29 May 1993 01:30:40 MESZ nasim.sta.sub.org Tue, 01 Jun 1993 00:46:06 MESZ nasim.sta.sub.org Thu, 03 Jun 93 10:48:04 MESZ aie.wu-wien.ac.at Fri, 4 Jun 93 10:56:33 MESZ exaib.wu-wien.ac.at Fri, 4 Jun 93 11:06:41 MESZ exaib.wu-wien.ac.at MEST Middle European Standard Time Tue, 25 May 93 12:45:47 MEST xivic.bo.open.de Tue, 25 May 93 14:20:53 MEST xivic.bo.open.de Tue, 25 May 93 14:48:22 MEST xivic.bo.open.de Wed, 26 May 93 23:22:22 MEST joker.wes.open.de Sat, 29 May 1993 18:22:55 MEST netmbx.netmbx.de Sat, 29 May 1993 18:21:07 MEST netmbx.netmbx.de Sun, 30 May 1993 12:57:21 MEST netmbx.netmbx.de Tue, 1 Jun 1993 21:51:09 MEST netmbx.netmbx.de MEZ Middle European Zone (used primarily in Germany) Mon, 10 May 93 20:47:50 MEZ rhrz.uni-bonn.de Wed, 26 May 93 12:59:57 MEZ vm.univie.ac.at ... Sun, 06 Jun 1993 14:32:28 MEZ sartar.toppoint.de Sun, 06 Jun 1993 18:37:50 MEZ sartar.toppoint.de UT Universal Time (used only by one system) 29 May 1993 21:14 UT kelvin.jpl.nasa.gov 31 May 1993 15:40 UT kelvin.jpl.nasa.gov ... 3 Jun 1993 21:36 UT kelvin.jpl.nasa.gov 4 Jun 1993 00:20 UT kelvin.jpl.nasa.gov WET+0100 Western European Time+0100 8 Apr 93 15:00:02 WET+0100 ittpub.nl 1 Jun 93 19:26:08 WET+0100 ittpub.nl 2 Jun 93 16:17:13 WET+0100 ittpub.nl 2 Jun 93 20:24:36 WET+0100 ittpub.nl 4 Jun 93 13:32:33 WET+0100 ittpub.nl 4 Jun 93 13:39:50 WET+0100 ittpub.nl 4 Jun 93 13:47:53 WET+0100 ittpub.nl 4 Jun 93 14:08:22 WET+0100 ittpub.nl Time zone abbreviations that are guesswork are: ARG Argentina? Tue, 25 May 93 12:46:21 ARG satlink.net Thu, 27 May 93 07:36:01 ARG satlink.net BSC ? Tue, 25 May 1993 10:51:05 BSC FINHUTC.HUT.FI Tue, 1 Jun 1993 11:57:00 BSC brfapesp.bitnet DST Daylight Saving Time? Thu, 27 May 93 11:00:24 DST cmrra.ca Thu, 27 May 93 23:31:02 DST cmrra.ca Fri, 28 May 93 17:26:14 DST cmrra.ca Sat, 29 May 93 16:48:42 DST cmrra.ca Sat, 29 May 93 16:54:30 DST cmrra.ca Sun, 30 May 93 14:38:30 DST cmrra.ca EDZ ? Mon, 31 May 93 18:14:42 EDZ wship.nullnet.fi Fri, 04 Jun 93 20:41:41 EDZ swob.nullnet.fi Fri, 04 Jun 93 20:53:45 EDZ swob.nullnet.fi EMT ? 28 Apr 1993 12:08:23 EMT alf.uib.no 29 Apr 1993 11:15:44 EMT alf.uib.no 29 Apr 1993 11:17:15 EMT alf.uib.no 28 May 1993 17:56:54 EMT alf.uib.no 1 Jun 1993 19:43:42 EMT alf.uib.no 3 Jun 1993 18:09:42 EMT alf.uib.no MEWT ? 12 May 93 07:41:03 MEWT mble.philips.be LCL LoCaL time? Tue, 1 Jun 1993 09:18:43 LCL kona.cc.mcgill.ca Wed, 2 Jun 1993 07:48:00 LCL mp.cs.niu.edu Wed, 2 Jun 1993 13:44:00 LCL mp.cs.niu.edu Thu, 3 Jun 1993 09:33:00 LCL oas2-tic.safb.af.mil Thu, 3 Jun 1993 08:25:39 LCL grouse.umesve.maine.edu Fri, 4 Jun 1993 20:09:05 LCL CUVMB.COLUMBIA.EDU Fri, 4 Jun 1993 20:19:59 LCL CUVMB.COLUMBIA.EDU NDT ? Tue, 25 May 1993 15:39:29 NDT UBVM.CC.BUFFALO.EDU SGP ? Mon, 31 May 93 15:43:36 SGP uwm.edu Fri, 4 Jun 93 10:20:26 SGP uwm.edu TUR Turkey? Wednesday, 5 May 1993 23:23:11 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:03:58 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:05:39 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:06:26 TUR TRMETU.BITNET Wednesday, 26 May 1993 20:47:38 TUR TRMETU.BITNET Thursday, 27 May 1993 10:15:14 TUR TRMETU.BITNET Thursday, 27 May 1993 12:28:59 TUR TREARN.BITNET Thursday, 27 May 1993 13:20:19 TUR TRMETU.BITNET Thursday, 27 May 1993 15:20:12 TUR TRMETU.BITNET Friday, 28 May 1993 11:01:42 TUR TREARN.BITNET Friday, 28 May 1993 12:53:52 TUR TRMETU.BITNET Sunday, 30 May 1993 12:15:24 TUR TREARN.BITNET Saturday, 29 May 1993 12:46:01 TUR TRMETU.BITNET Monday, 31 May 1993 21:44:49 TUR TRMETU.BITNET Saturday, 5 Jun 1993 18:30:45 TUR TREARN.BITNET Sunday, 6 Jun 1993 13:14:56 TUR TREARN.BITNET TZONE ? Mon, 31 May 1993 05:01:19 TZONE VAXF.COLORADO.EDU Wed, 2 Jun 1993 19:59:49 TZONE carson.u.washington.edu Fri, 4 Jun 1993 09:21:33 TZONE sunburn.uwaterloo.ca XDT ? Tue, 25 May 1993 10:20:55 XDT sfanet.nrl.navy.mil The results make me think there's little prospect of discovering useful time zone information (in particular, time transitions that don't already show up in tzdata93c.tar.Z) from running through news articles; someone with an account on a site that does extensive archiving of news might prove me wrong. --ado

2 1

Re: time zone survey
by guy＠auspex.com June 11, 1993

June 11, 1993

> (Yes, in SysV the file has to be changed every > year again. And SGI shows no inclination to change.) Actually, I think SVR4 includes the Olson code, although I don't think all SVR4.0 systems supply the Olson files. However, I infer from one of Eric Raymond's lists of SVR4 bugs that SVR4.2 does supply the Olson files *and* uses Olson-style timezone specifications (":" followed by the time zone file name) by default. (The bug was that SVR4.0 binaries allegedly don't work with SVR4.2 time zone names, an example of which was given as "US/Eastern" or something such as that; that seems a *tad* bizarre, as if SVR4.0 has the Olson code, SVR4.0 statically-linked binaries should be able to handle Olson-style names, and SVR4.0 dynamically-linked binaries should use SVR4.2 shared libraries and should thus also be able to handle them. Perhaps the bug was that SVR3.x binaries don't handle Olson-style names.) SVR4 uses "/etc/TIMEZONE", but you can set TZ to ":MET" and you shouldn't have to change it every year. (Also, SVR4 should also support POSIX-style TZ settings, which should allow you to put in a value that doesn't require periodic updates *if* your locale's DST rules are sufficiently "regular" that they can be encoded in the TZ setting. I don't know which SVR3.x systems, if any, supported that.) If, as, and when IRIX goes to an SVR4 base, they should probably pick up the Olson code with it.

1 0

Re: time zone survey
by Dik.Winter＠cwi.nl June 11, 1993

June 11, 1993

> Attached are results from a casual time zone survey. An interesting survey. > I tossed out data with unzoned time stamps, data without a recognizable > domained system name in the Message-ID, and data from ".com" sites. Why did you toss out data from ".com" sites? > 1 +0530 > 1 Jun 93 15:30:55 +0530 imtech.ernet.in This might be a valid one. It is apparently from India which lives around +5 and +6. > 1 +0611 > Wed, 02 Jun 93 16:08:33 +0611 trashcan.hacktic.nl This one is definitely invalid. Most probably a PC hooked up to hacktic (a public access system in the Netherlands). Probably the owner did set it up wrong. > 1 +0730 > 6 Jun 1993 08:25:56 +0730 news.Colorado.EDU Ha! If even Colorado.Edu cannot get it correct! ;-). > MESZ Middle European Standard Zone Probably "Mittel Europ"aische Standard Zeit". > MEZ Middle European Zone (used primarily in Germany) "Mittel Europ"aische Zeit". And yes, primarily german speaking countries. > BSC ? > Tue, 25 May 1993 10:51:05 BSC FINHUTC.HUT.FI > Tue, 1 Jun 1993 11:57:00 BSC brfapesp.bitnet These two are definitely not in the same timezone. One is in Finland, one in Brazil. > TUR Turkey? Probably yes. All sites are in Turkey. > The results make me think there's little prospect of discovering useful > time zone information (in particular, time transitions that don't already > show up in tzdata93c.tar.Z) from running through news articles; someone > with an account on a site that does extensive archiving of news might prove > me wrong. I think there is no prospect at all. And it will grow worse. In the case of the "hacktic.nl" machine we see that we have a single machine that is configured wrong. I think more of this kind of machines will emerge. They do not care what time the system runs on, as long as it is internally consistent (and even that is not needed at all times). Time transitions especially will be a problem, and it will continue to be a problem. At our institute during the transition to DST all Suns (which use your package) switched on time, but all SGI's (using SysV's method) did not. The system administrator simply had forgotten to update the file that contained timezone information (/etc/TIMEZONE) and it took a few days before somebody noticed. (Yes, in SysV the file has to be changed every year again. And SGI shows no inclination to change.) So I think nobody will prove you wrong.

1 0

Re: "32 time zones"
by Amos Shapir June 9, 1993

June 9, 1993

> I don't know about any zones with > three-quarter hour offsets, but would like to know what they are. >From the same usno1989 file (which is outdated and contains errors, but seems to be the most comprehensive source we have): NEPAL 5H45M AHEAD OF UTC NEW ZEALAND 12H45M AHEAD OF UTC CHATHAM ISLAND In the Rand-McNally atlas there are a few other Pacific islands with 40 mins offsets, all of which appear as full or half-hour zones in the file; it also lists Nepal at GMT+5:40 and Liberia as -0:44 (yes, forty four) -- makes sense since Monrovia is at exactly 11 degrees west, but probably outdated too. Amos Shapir Net: amos(a)cs.huji.ac.il Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N

2 1

"32 time zones"
by ado June 8, 1993

June 8, 1993

Our society has created a fictional time system of 32 time zones (24 one-hour offsets and several more half-hour and three-quarter hour offsets). --Tognazzini, Bruce (tog(a)eng.sun.com) "Tog on Interface: The Myth of Precision", Sun World, volume 6, number 7 (June, 1993), page 100. A grep in /usr/lib/zoneinfo/* on a SunOS 4.1.1 system failed to show up eight oddball time zones (see attached). Does anyone know of the origin for the "32" time zones? --ado

3 3

Re: "32 time zones"
by tog＠cloud9.Eng.Sun.COM June 8, 1993

June 8, 1993

Well, so much for my books are better than computers theory. Still and all, I can think of no atlas that would manage to tell one person there were 24 zones and another person there were 40 zones. We have a long way to go not only in information storage, but in responsive retrieval. -Tog > From amos(a)cs.huji.ac.il Tue Jun 8 07:02:26 1993 > To: ado(a)bossie.nci.nih.gov (Arthur David Olson) > Subject: Re: "32 time zones" > Cc: tog@Eng, tz(a)bossie.nci.nih.gov > Content-Length: 579 > X-Lines: 13 > > Well, you didn't grep hard enough; I just did: > > grep '[.H][0-9]' /usr/share/lib/zoneinfo/usno1989 > > And got 11 part-hour zones, 3 of which apply DST which can be also counted as > separate timezones; plus Russia's East Siberia zone which is 13 hours ahead of > GMT and 14 with DST. In total, we have 24+12+4 or 40 time zones, 36 of which > are in use somewhere at any given time. > > Amos Shapir Net: amos(a)cs.huji.ac.il > Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. > Givat-Ram, Jerusalem 91904, Israel > Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N >

1 0

Re: "32 time zones"
by tog＠cloud9.Eng.Sun.COM June 8, 1993

June 8, 1993

Try any (printed) atlas. Or wait until the next century when computers just barely begin to catch up with where printed matter was 300 years ago. Grepping indeed! -Tog > From ado(a)bossie.nci.nih.gov Tue Jun 8 06:40:56 1993 > To: amos(a)cs.huji.ac.il, tog@Eng, tz(a)bossie.nci.nih.gov > Subject: "32 time zones" > Content-Length: 481 > X-Lines: 13 > > Our society has created a fictional time system of 32 time zones > (24 one-hour offsets and several more half-hour and three-quarter > hour offsets). > > --Tognazzini, Bruce (tog(a)eng.sun.com) "Tog on Interface: > The Myth of Precision", Sun World, volume 6, number 7 > (June, 1993), page 100. > > A grep in /usr/lib/zoneinfo/* on a SunOS 4.1.1 system failed to show up eight > oddball time zones (see attached). Does anyone know of the origin for the > "32" time zones? > > --ado >

1 0

Re: "32 time zones"
by Amos Shapir June 8, 1993

June 8, 1993

Well, you didn't grep hard enough; I just did: grep '[.H][0-9]' /usr/share/lib/zoneinfo/usno1989 And got 11 part-hour zones, 3 of which apply DST which can be also counted as separate timezones; plus Russia's East Siberia zone which is 13 hours ahead of GMT and 14 with DST. In total, we have 24+12+4 or 40 time zones, 36 of which are in use somewhere at any given time. Amos Shapir Net: amos(a)cs.huji.ac.il Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N

1 0

tzcode93c.tar.Z and tzdata93c.tar.Z
by ado June 6, 1993

June 6, 1993

The latest versions of the time zone stuff are available in the files tzcode93c.tar.Z and tzdata93c.tar.Z in the ~ftp/pub directory on elsie.nci.nih.gov (128.231.16.1). --ado

1 0

Revised draft strftime.c
by ado May 30, 1993

May 30, 1993

An updated draft is available on elsie.nci.nih.gov as ~ftp/pub/draft-strftime.tar.Z, which includes strftime.c and the header files it references. The draft version incorporates the shift to use of sprintf to generate output. This makes the code simpler; it may irk folks who get the standard input/output library dragged in when they call strftime. The handling of "%D" and "%x" have been separated so that they can be changed independently. Right now they're still treated identically in the code; comments have been added giving other possibilities for "%x" handling. The worry is that some piece of code out there is counting on the current "%x" behavior and will break if it is changed. (Yes, counting on "%x" behavior is worng.) As always, any comments are welcome. --ado

1 0

more on ISO date format
by eggert＠spot.twinsun.com May 30, 1993

May 30, 1993

I did some more research on ISO date format, and discovered that the ISO 2014 standard has been superseded by ISO 8601:1988. The date format hasn't changed, however. You can find a summary of ISO 8601:1988 in ftp.uni-erlangen.de:pub/doc/ISO/english/ISO8601.ps.Z.

1 0

Re: proposed changes to strftime.c
by ado May 30, 1993

May 30, 1993

> Use ISO standard date format for %x; this is more appropriate than the > American date format, which confuses non-Americans. Especially for > dates like 01/02/03; the ISO date 2003-01-02 is much clearer for > everybody, and it sorts correctly too. Does "ISO standard date format" hear mean that YYYY-MM-DD is what the ISO version of the C language standard requires, or does it mean something else? --ado

2 1

strftime.c tuneups
by eggert＠twinsun.com May 26, 1993

May 26, 1993

Here are a couple of performance tuneups for strftime.c. 1. Instead of using arrays of pointers to arrays of chars, use two-dimensional arrays of chars, since the sizes are all known. This tends to use less space (since you don't need to store the pointers) and time (since you don't need to indirect through them. 2. Instead of passing around a pointer and pointer to size, incrementing the former and decrementing the latter indirectly, just pass around a pointer and its limit. That way, you can avoid the extra indirection and decrementation. These two changes lop 10% off the code size (sparc, GCC 2.4.0 with -O2). Here's a patch, which assumes my previous patch was applied. *** draft-strftime1.c Tue May 25 11:28:38 1993 --- draft-strftime2.c Tue May 25 21:07:08 1993 *************** *** 32,56 **** #include "private.h" #include "tzfile.h" ! static const char * const afmt[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; ! static const char * const Afmt[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }; ! static const char * const bfmt[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; ! static const char * const Bfmt[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }; ! static char *_add P((const char *, size_t *, char *)); ! static char *_conv P((int, const char *, size_t *, char *)); ! static char *_fmt P((const char *, const struct tm *, size_t *, char *)); size_t strftime P((char *, size_t, const char *, const struct tm *)); --- 32,56 ---- #include "private.h" #include "tzfile.h" ! static const char afmt[][4] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; ! static const char Afmt[][10] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }; ! static const char bfmt[][4] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; ! static const char Bfmt[][10] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }; ! static char *_add P((const char *, char *, const char *)); ! static char *_conv P((int, const char *, char *, const char *)); ! static char *_fmt P((const char *, const struct tm *, char *, const char *)); size_t strftime P((char *, size_t, const char *, const struct tm *)); *************** *** 61,82 **** const char *format; const struct tm *t; { ! size_t gsize; ! gsize = maxsize; ! s = _fmt(format, t, &gsize, s); ! if (gsize <= 0) return 0; ! *s = '\0'; ! return maxsize - gsize; } static char * ! _fmt(format, t, gsizep, pt) const char *format; const struct tm *t; - size_t *gsizep; char *pt; { for (; *format; ++format) { if (*format == '%') { --- 61,81 ---- const char *format; const struct tm *t; { ! char *p; ! p = _fmt(format, t, s, s + maxsize); ! if (p == s + maxsize) return 0; ! *p = '\0'; ! return p - s; } static char * ! _fmt(format, t, pt, ptlim) const char *format; const struct tm *t; char *pt; + const char *ptlim; { for (; *format; ++format) { if (*format == '%') { *************** *** 87,109 **** break; case 'A': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : Afmt[t->tm_wday], gsizep, pt); continue; case 'a': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : afmt[t->tm_wday], gsizep, pt); continue; case 'B': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : Bfmt[t->tm_mon], gsizep, pt); continue; case 'b': case 'h': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : bfmt[t->tm_mon], gsizep, pt); continue; case 'c': ! pt = _fmt("%D %X", t, gsizep, pt); continue; case 'C': /* --- 86,108 ---- break; case 'A': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : Afmt[t->tm_wday], pt, ptlim); continue; case 'a': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : afmt[t->tm_wday], pt, ptlim); continue; case 'B': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : Bfmt[t->tm_mon], pt, ptlim); continue; case 'b': case 'h': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : bfmt[t->tm_mon], pt, ptlim); continue; case 'c': ! pt = _fmt("%D %X", t, pt, ptlim); continue; case 'C': /* *************** *** 114,120 **** ** (ado, 5/24/93) */ pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, ! "%02d", gsizep, pt); continue; case 'D': case 'x': --- 113,119 ---- ** (ado, 5/24/93) */ pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, ! "%02d", pt, ptlim); continue; case 'D': case 'x': *************** *** 129,138 **** ** numbers (as here) makes Quakers happier. ** This is the ISO standard date format. */ ! pt = _fmt("%Y-%m-%d", t, gsizep, pt); continue; case 'd': ! pt = _conv(t->tm_mday, "%02d", gsizep, pt); continue; case 'E': case 'O': --- 128,137 ---- ** numbers (as here) makes Quakers happier. ** This is the ISO standard date format. */ ! pt = _fmt("%Y-%m-%d", t, pt, ptlim); continue; case 'd': ! pt = _conv(t->tm_mday, "%02d", pt, ptlim); continue; case 'E': case 'O': *************** *** 149,166 **** */ goto label; case 'e': ! pt = _conv(t->tm_mday, "%2d", gsizep, pt); continue; case 'H': ! pt = _conv(t->tm_hour, "%02d", gsizep, pt); continue; case 'I': pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%02d", gsizep, pt); continue; case 'j': ! pt = _conv(t->tm_yday + 1, "%03d", gsizep, pt); continue; case 'k': /* --- 148,165 ---- */ goto label; case 'e': ! pt = _conv(t->tm_mday, "%2d", pt, ptlim); continue; case 'H': ! pt = _conv(t->tm_hour, "%02d", pt, ptlim); continue; case 'I': pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%02d", pt, ptlim); continue; case 'j': ! pt = _conv(t->tm_yday + 1, "%03d", pt, ptlim); continue; case 'k': /* *************** *** 173,186 **** ** "%l" have been swapped. ** (ado, 5/24/93) */ ! pt = _conv(t->tm_hour, "%2d", gsizep, pt); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ ! pt = _add("kitchen sink", gsizep, pt); continue; #endif /* defined KITCHEN_SINK */ case 'l': --- 172,185 ---- ** "%l" have been swapped. ** (ado, 5/24/93) */ ! pt = _conv(t->tm_hour, "%2d", pt, ptlim); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ ! pt = _add("kitchen sink", pt, ptlim); continue; #endif /* defined KITCHEN_SINK */ case 'l': *************** *** 195,234 **** */ pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%2d", gsizep, pt); continue; case 'M': ! pt = _conv(t->tm_min, "%02d", gsizep, pt); continue; case 'm': ! pt = _conv(t->tm_mon + 1, "%02d", gsizep, pt); continue; case 'n': ! pt = _add("\n", gsizep, pt); continue; case 'p': pt = _add(t->tm_hour >= 12 ? "PM" : "AM", ! gsizep, pt); continue; case 'R': ! pt = _fmt("%H:%M", t, gsizep, pt); continue; case 'r': ! pt = _fmt("%I:%M:%S %p", t, gsizep, pt); continue; case 'S': ! pt = _conv(t->tm_sec, "%02d", gsizep, pt); continue; case 'T': case 'X': ! pt = _fmt("%H:%M:%S", t, gsizep, pt); continue; case 't': ! pt = _add("\t", gsizep, pt); continue; case 'U': pt = _conv((t->tm_yday + 7 - t->tm_wday) / 7, ! "%02d", gsizep, pt); continue; case 'u': /* --- 194,233 ---- */ pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%2d", pt, ptlim); continue; case 'M': ! pt = _conv(t->tm_min, "%02d", pt, ptlim); continue; case 'm': ! pt = _conv(t->tm_mon + 1, "%02d", pt, ptlim); continue; case 'n': ! pt = _add("\n", pt, ptlim); continue; case 'p': pt = _add(t->tm_hour >= 12 ? "PM" : "AM", ! pt, ptlim); continue; case 'R': ! pt = _fmt("%H:%M", t, pt, ptlim); continue; case 'r': ! pt = _fmt("%I:%M:%S %p", t, pt, ptlim); continue; case 'S': ! pt = _conv(t->tm_sec, "%02d", pt, ptlim); continue; case 'T': case 'X': ! pt = _fmt("%H:%M:%S", t, pt, ptlim); continue; case 't': ! pt = _add("\t", pt, ptlim); continue; case 'U': pt = _conv((t->tm_yday + 7 - t->tm_wday) / 7, ! "%02d", pt, ptlim); continue; case 'u': /* *************** *** 238,244 **** ** (ado, 5/24/93) */ pt = _conv((t->tm_wday == 0) ? 7 : t->tm_wday, ! "%d", gsizep, pt); continue; case 'V': /* --- 237,243 ---- ** (ado, 5/24/93) */ pt = _conv((t->tm_wday == 0) ? 7 : t->tm_wday, ! "%d", pt, ptlim); continue; case 'V': /* *************** *** 270,276 **** i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; pt = _conv((i == 0) ? 53 : i, ! "%02d", gsizep, pt); } continue; case 'v': --- 269,275 ---- i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; pt = _conv((i == 0) ? 53 : i, ! "%02d", pt, ptlim); } continue; case 'v': *************** *** 279,315 **** ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ ! pt = _fmt("%e-%b-%Y", t, gsizep, pt); continue; case 'W': pt = _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, ! "%02d", gsizep, pt); continue; case 'w': ! pt = _conv(t->tm_wday, "%d", gsizep, pt); continue; case 'y': pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, ! "%02d", gsizep, pt); continue; case 'Y': pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! gsizep, pt); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) ! pt = _add(t->TM_ZONE, gsizep, pt); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; pt = _add(tzname[t->tm_isdst], ! gsizep, pt); ! } else pt = _add("?", gsizep, pt); continue; case '%': /* --- 278,314 ---- ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ ! pt = _fmt("%e-%b-%Y", t, pt, ptlim); continue; case 'W': pt = _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, ! "%02d", pt, ptlim); continue; case 'w': ! pt = _conv(t->tm_wday, "%d", pt, ptlim); continue; case 'y': pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, ! "%02d", pt, ptlim); continue; case 'Y': pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! pt, ptlim); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) ! pt = _add(t->TM_ZONE, pt, ptlim); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; pt = _add(tzname[t->tm_isdst], ! pt, ptlim); ! } else pt = _add("?", pt, ptlim); continue; case '%': /* *************** *** 321,356 **** break; } } ! if (*gsizep <= 0) return pt; *pt++ = *format; - --*gsizep; } return pt; } static char * ! _conv(n, format, gsizep, pt) int n; const char *format; - size_t *gsizep; char *pt; { char buf[21]; /* Room for - 2**63 ("-9223372036854775808") + null. */ (void) sprintf(buf, format, n); ! return _add(buf, gsizep, pt); } static char * ! _add(str, gsizep, pt) const char *str; - size_t *gsizep; char *pt; { ! while (*gsizep > 0 && (*pt = *str++) != '\0') { ++pt; - --*gsizep; } return pt; } --- 320,353 ---- break; } } ! if (pt == ptlim) return pt; *pt++ = *format; } return pt; } static char * ! _conv(n, format, pt, ptlim) int n; const char *format; char *pt; + const char *ptlim; { char buf[21]; /* Room for - 2**63 ("-9223372036854775808") + null. */ (void) sprintf(buf, format, n); ! return _add(buf, pt, ptlim); } static char * ! _add(str, pt, ptlim) const char *str; char *pt; + const char *ptlim; { ! while (pt < ptlim && (*pt = *str++) != '\0') { ++pt; } return pt; }

1 0

updated strftime.c
by ado May 25, 1993

May 25, 1993

An updated draft strftime.c, with changes from Bradley White (bww+(a)transarc.com) to avoid problems on multiprocessor systems, is available for anonymous ftp from elsie.nci.nih.gov (128.231.16.1) in the "pub" directory, file "draft-strftime.c". As Bradley noted in correspondence, it also: - removes _conv()'s static [non-const] buffer - corrects a problem with _conv() most easily seen with "%k" when tm_hour == 0 - can use the first char of _conv()'s new, non-static buffer - eliminates _conv()'s ASCII dependency - adds a missing _fmt()-parameter in the "%v" case (I've reformatted "strftime.c" just slightly from what bww sent me.) Again, any and all feedback is welcome; correspondence might best be sent to tz(a)elsie.nci.nih.gov. --ado

2 1

impending tzcode93b.tar.Z
by ado May 24, 1993

May 24, 1993

Having received useful changes from several sources, I'm hoping to put up tzcode93b.tar.Z for anonymous ftp soon. One thing I'd like to do is bring "strftime" up to date with new standards (akin to Arnold Robbins' version). A proposed "strftime" is attached; grepping for "5/24/93" will show up where changes have happened. Any comments would be appreciated; I'd particularly like word on the matter marked by "XXX" below. --ado #ifndef lint #ifndef NOID static char elsieid[] = "@(#)strftime.c 7.2"; /* ** Based on the UCB version whose ID appears below. ** This is ANSIish only when time is treated identically in all locales and ** when "multibyte character == plain character". */ #endif /* !defined NOID */ #endif /* !defined lint */ /* * Copyright (c) 1989 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)strftime.c 5.4 (Berkeley) 3/14/89"; #endif /* LIBC_SCCS and not lint */ #include "sys/types.h" #include "time.h" #include "tzfile.h" static char *afmt[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", }; static char *Afmt[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", }; static char *bfmt[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", }; static char *Bfmt[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; static size_t gsize; static char *pt; static void _add(); static void _conv(); static void _fmt(); size_t strftime(s, maxsize, format, t) char *s; char *format; size_t maxsize; struct tm *t; { pt = s; gsize = maxsize; _fmt(format, t); if (gsize <= 0) return(0); *pt = '\0'; return(maxsize - gsize); } static void _fmt(format, t) register char *format; struct tm *t; { for (; *format; ++format) { if (*format == '%') { label: switch(*++format) { case '\0': --format; break; case 'A': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(Afmt[t->tm_wday]); continue; case 'a': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(afmt[t->tm_wday]); continue; case 'B': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(Bfmt[t->tm_mon]); continue; case 'b': case 'h': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(bfmt[t->tm_mon]); continue; case 'c': _fmt("%D %X", t); continue; case 'C': /* ** %C used to do a... ** _fmt("%a %b %e %X %Y", t); ** ...whereas now POSIX 1003.2 calls for ** something completely different. ** (ado, 5/24/93) */ _conv((t->tm_year + TM_YEAR_BASE) / 100, 2, '0'); continue; case 'D': case 'x': /* ** Version 3.0 of strftime from Arnold Robbins ** (arnold(a)skeeve.atl.ga.us) does the ** equivalent of... ** _fmt("%a %b %e %Y"); ** ...for %x; since the X3J11 C language ** standard calls for "date, using locale's ** date format," anything goes. Using just ** numbers (as here) makes Quakers happier. ** (ado, 5/24/93) */ _fmt("%m/%d/%y", t); continue; case 'd': _conv(t->tm_mday, 2, '0'); continue; case 'E': case 'O': /* ** POSIX locale extensions, a la ** Arnold Robbins' strftime version 3.0. ** The sequences ** %Ec %EC %Ex %Ey %EY ** %Od %oe %OH %OI %Om %OM ** %OS %Ou %OU %OV %Ow %OW %Oy ** are supposed to provide alternate ** representations. ** (ado, 5/24/93) */ goto label; case 'e': _conv(t->tm_mday, 2, ' '); continue; case 'H': _conv(t->tm_hour, 2, '0'); continue; case 'I': _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, '0'); continue; case 'j': _conv(t->tm_yday + 1, 3, '0'); continue; case 'k': /* ** This used to be... ** _conv(t->tm_hour % 12 ? ** t->tm_hour % 12 : 12, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbins' ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour, 2, ' '); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ _add("kitchen sink"); continue; #endif /* defined KITCHEN_SINK */ case 'l': /* ** This used to be... ** _conv(t->tm_hour, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbin's ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, ' '); continue; case 'M': _conv(t->tm_min, 2, '0'); continue; case 'm': _conv(t->tm_mon + 1, 2, '0'); continue; case 'n': _add("\n"); continue; case 'p': _add(t->tm_hour >= 12 ? "PM" : "AM"); continue; case 'R': _fmt("%H:%M", t); continue; case 'r': _fmt("%I:%M:%S %p", t); continue; case 'S': _conv(t->tm_sec, 2, '0'); continue; case 'T': case 'X': _fmt("%H:%M:%S", t); continue; case 't': _add("\t"); continue; case 'U': _conv((t->tm_yday + 7 - t->tm_wday) / 7, 2, '0'); continue; case 'u': /* ** From Arnold Robbins' strftime version 3.0: ** "ISO 8601: Weekday as a decimal number ** [1 (Monday) - 7]" ** (ado, 5/24/93) */ _conv(((t->tm_wday == 0) ? 7 : t->tm_wday), 1, '0'); continue; case 'V': /* ** From Arnold Robbins' strftime version 3.0: ** "the week number of the year (the first ** Monday as the first day of week 1) as a ** decimal number (01-53). The method for ** determining the week number is as specified ** by ISO 8601 (to wit: if the week containing ** January 1 has four or more days in the new ** year, then it is week 1, otherwise it is ** week 53 of the previous year and the next ** week is week 1)." ** (ado, 5/24/93) */ /* ** XXX--If January 1 falls on a Friday, ** January 1-3 are part of week 53 of the ** previous year. By analogy, if January ** 1 falls on a Thursday, are December 29-31 ** of the PREVIOUS year part of week 1??? ** (ado 5/24/93) /* ** You are understood not to expect this. */ { register int i; i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; _conv((i == 0) ? 53 : i, 2, '0'); } continue; case 'v': /* ** From Arnold Robbins' strftime version 3.0: ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ _fmt("%e-%b-%Y"); continue; case 'W': _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, 2, '0'); continue; case 'w': _conv(t->tm_wday, 1, '0'); continue; case 'y': _conv((t->tm_year + TM_YEAR_BASE) % 100, 2, '0'); continue; case 'Y': _conv(t->tm_year + TM_YEAR_BASE, 4, '0'); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) _add(t->TM_ZONE); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; _add(tzname[t->tm_isdst]); } else _add("?"); continue; case '%': /* * X311J/88-090 (4.12.3.5): if conversion char is * undefined, behavior is undefined. Print out the * character itself as printf(3) also does. */ default: break; } } if (gsize <= 0) return; *pt++ = *format; --gsize; } } static void _conv(n, digits, fill) int n, digits, fill; { static char buf[10]; register char *p; for (p = buf + sizeof(buf) - 2; n > 0 && p > buf; n /= 10, --digits) *p-- = n % 10 + '0'; while (p > buf && digits-- > 0) *p-- = fill; _add(++p); } static void _add(str) register char *str; { for (;; ++pt, --gsize) { if (gsize <= 0) return; if (!(*pt = *str++)) return; } }

1 0

A brief history of (and agenda for) time zone libraries
by eggert＠twinsun.com May 15, 1993

May 15, 1993

Summary: The GNU C library is derived from Arthur David Olson's 1989 time zone code, with extensive changes. The good news is that these changes improve the modularity of Olson's code; the bad news is that it is now hard to merge some of Olson's more recent improvements into the GNU C library. Despite the bad news, Olson's fixes and improvements should be merged into the GNU C library somehow. While we're on the subject, the Linux time zone code also comes from Olson's 1989 code, but has only few minor changes; it should be updated to the current edition of Olson's code. __________ Olson's 1989 code. The original timezone code was written by Arthur David Olson. This public domain code has a good reputation. Even the Posix standard comes as close as a standard can to saying ``This is good stuff -- check it out!''; see Posix 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. GNU C Library. The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is derived from Olson's 1989 code. Here are its changes: 1. Rewrite the Makefile to use GNU make and GNU libc standards. 2. Split localtime.c into several smaller, more modular files. These files are: __tzset.c gmtime.c mktime.c offtime.c tzfile.c tzset.c. Completely rewrite these files in the GNU style. 3. Add some time functions not in Olson's package, e.g. adjtime. 4. Update some of the New Zealand time zone rules. Linux. Linux's code for timezones (see tsx-11.mit.edu:pub/linux/sources/sbin/timesrc.tar.Z) is also derived from Olson's 1989 code, but it has only the following minor changes: 1. Rewrite the Makefile to meet Linux standards. 2. Add a few #includes, or change them from "" form to <> form. Olson's current edition. Arthur David Olson is still maintaining both the code and the corresponding timezone database (see elsie.nci.nih.gov:pub/tz*). The differences between Olson's 1989 code and his current edition are as follows: 1. Fix some minor Makefile portability problems. 2. Fix some bugs in the C code, and avoid some possible core dumps. 3. Bring the leap second database up-to-date through June 1993. 4. Update the time zone database for Israel, Australia (which is particularly wild and woolly -- they hold voter referendums to change the timezone rules!), New Zealand, Britain, Portugal, Starke County Indiana, Saskatchewan. Remove the nonexistent US Pacific Presidential Election Time, which caused some problems late last year on some West Coast Suns. The New Zealand updates are a superset of the GNU C library's updates. 5. Add a -y option to zic to specify a command that tests for arbitrary year types; this is used in some of the new time zone rules. Proposal. Olson's changes should be propagated into both Linux and the GNU C library. Linux should update to Olson's current edition; this should be a simple merge. By the way, the Linux code should also give credit to Olson instead of silently removing his README file; this will help prevent the current situation from recurring. The GNU C library changes fall into two categories: (A) changes to Olson's localtime.c, and (B) everything else. Merging (B) is easy, almost as easy as merging the Linux timezone code, and I've already submitted patches to the GNU C library developers to do this. Merging (A) is harder, since the GNU C library has split up localtime.c into lots of little pieces. The GNU C library changes generally improve Olson's code -- they make the module interfaces cleaner, and the code is easier to follow. Unfortunately, it is now hard to tell how to propagate Olson's localtime.c changes and improvements into the GNU C library. The best person to do this propagation is the person who split up localtime.c in the first place. Another possibility is for the GNU C library to switch to a version of localtime.c that is as close as possible to Olson's latest version; that might simplify future maintenance.

2 2

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

Improvidently, a couple of things make buying back the GNU changes at this end difficult. One is not so bad. Since the GNU folks are clearly implementers (in the ANSI sense of the word), they're entitled to use names from the implementers' name space in their code; this means that strictly internal functions can be split into separate source files without polluting the user's name space. It's not clear that this is kosher when the timezone package is distributed independently. But some care in packaging and some creative use of the preprocessor would avoid most challenges here. One is not so tractable. Buying back the GNU code at this point would also involve putting things under the GPL, which I'm loathe to do. --ado

1 0

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

> From roland(a)gnu.ai.mit.edu Sat May 15 18:14:48 1993 > Return-Path: <roland(a)gnu.ai.mit.edu> > Received: from churchy.gnu.ai.mit.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA22472; Sat, 15 May 93 18:14:34 EDT > Received: by churchy.gnu.ai.mit.edu (5.65/4.0) > id <AA21556(a)churchy.gnu.ai.mit.edu>; Sat, 15 May 93 18:14:01 -0400 > Date: Sat, 15 May 93 18:14:01 -0400 > From: roland(a)gnu.ai.mit.edu (Roland McGrath) > Message-Id: <9305152214.AA21556(a)churchy.gnu.ai.mit.edu> > To: eggert(a)twinsun.com > Cc: libc-alpha(a)gnu.ai.mit.edu, tz(a)elsie.nci.nih.gov > Subject: Re: A brief history of (and agenda for) time zone libraries > In-Reply-To: Paul Eggert's message of Sat, 15 May 93 00:08:44 PDT <9305150708.AA18312(a)bi.twinsun.com> > X-Shopping-List: (1) Hot mutant holidays > (2) Apologetic interruptions > (3) Frenetic lesions > > > Olson's 1989 code. > > > > The original timezone code was written by Arthur David Olson. This public > > domain code has a good reputation. Even the Posix standard comes as close as > > a standard can to saying ``This is good stuff -- check it out!''; see Posix > > 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of > > Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see > > ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. > > I wish I had known that this code was being maintained, and where to get it > from, before now. > > > Proposal. > > > > Olson's changes should be propagated into both Linux and the GNU C library. > > Indeed. Linux is not my concern, but I plan to update glibc today. > > > The GNU C library changes fall into two categories: (A) changes to > > Olson's localtime.c, and (B) everything else. Merging (B) is easy, > > almost as easy as merging the Linux timezone code, and I've already > > submitted patches to the GNU C library developers to do this. Merging > > (A) is harder, since the GNU C library has split up localtime.c into lots > > of little pieces. The GNU C library changes generally improve Olson's > > code -- they make the module interfaces cleaner, and the code is easier > > to follow. > > These issues are very important to the GNU project, and to me. > > > Unfortunately, it is now hard to tell how to propagate Olson's > > localtime.c changes and improvements into the GNU C library. The best > > person to do this propagation is the person who split up localtime.c in > > the first place. > > I am that person, and I plan to do the work. > > > Another possibility is for the GNU C library to switch to a version of > > localtime.c that is as close as possible to Olson's latest version; that > > might simplify future maintenance. > > I really don't want to do this. It took me quite a while to untangle the > spaghetti in the first place. This would certainly not simplify > maintenance of the glibc code; it would return it to the obfuscated > spaghetti I started with. Having the code be modular and clean simplifies > maintenance for me. Using code close Olsen's code only simplifies future > merging with Olsen's code. >

1 0

proactive DST discovery?
by ado May 13, 1993

May 13, 1993

If you have insights on the advisability of doing network polling to learn of time changes, or have notions on how it might best be done, I'd appreciate your sharing them with tz(a)elsie.nci.nih.gov. -- Arthur David Olson ado(a)elsie.nci.nih.gov ADO and Elsie are Ampex and Borden trademarks "REM AND STINPY"--found in Bill Gates' startup file

1 0

Daylight savings time
by Monty Solomon May 3, 1993

May 3, 1993

An associate is looking for a source of information regarding the rules for daylight savings time in different countries. He has the North American rules but needs to find a source for Europe, etc. Do other countries observe daylight savings? Thanks. Monty --- # Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405 # monty%roscom(a)think.com

1 0

Re: tzload memory leak?
by Joel.Tornatore＠Eng.Sun.COM April 23, 1993

April 23, 1993

Stephen, I have been out the for the last week (since 4/16, as a matter of fact.....Santa Fe was great!) so if this problem has not been resolved, please let me know. The problem was noticed in Solaris 2.0, and fixed in a patch to SunOS 4.1.3. You will also notice that the tzfile being used is opened and read for each call to tzset(), and the memory was not being freed. I can get you a new libc if necessary. joel > From eubank(a)predict.com Fri Apr 16 16:58 PDT 1993 > To: tz(a)elsie.nci.nih.gov > Subject: tzload memory leak? > > I've been using an application (under SunOS 4.1.3) > which switches time zones frequently. > It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. Since it would hardly be noticeable to anyone > who didn't happen to be using (or abusing) tzset thousands of times, > I wouldn't be surprised if it hadn't been noticed before. On the off > chance that someone out there has encountered it, can you send me > pointers to patches, workarounds, etc.? I can't switch to Solaris yet. > > Here are some details: > I profile this code: > > #include <time.h> > > main() > { > int i; > for (i=0; i<100; i++) { > tzset(); > } > } > > > and find that malloc is called roughly 400 times, while free is called > roughly 300 times. If I increase the number of iterations in the loop > tp 1000, the calls to malloc and free go up by a factor of 10. malloc is > being called from calloc, which is being called from allocall, which is > being called from tzload. It looks to me like tzload allocates 4 things > and only frees 3 of them each time it is called. > > Thanks for any help you can give me. > > Stephen Eubank > eubank(a)predict.com >

1 0

Re: tzload memory leak?
by guy＠auspex.com April 17, 1993

April 17, 1993

> It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. The data that's mallocated by the time zone stuff in SunOS 4.x is: the array of transition times; the array of information about the State Of The Time Zone after a given transition time (offset from GMT, DST or not, index into the list of time zone abbreviation strings, etc.); the array of time zone types (indices into the array of information about the State Of The Time Zone after a given transition time); the array of "char"s that contains the aforementioned abbreviation strings. Applications can't get a pointer to any of the first three items, so they can be freed whenever "tzset()" is called. However, it appears that the array containing abbreviation strings isn't freed because, according to the comment, it "might have other references to it", presumably obtained by using the "tzname[]" array (in the SV environment) or by using the "tm_zone" member of "struct tm". Now, from the way I read POSIX 1003.1, it neither commits to pointers fetched from "tzname[]" remaining valid after a call to "tzset()", nor explicitly claims that one should *not* assume they'll still point somewhere valid. The "ctime" manual page *does*, however, explicitly note that calls to "tzset()" or "tzsetwall()" overwrite the array to which the "tm_zone" field points. So I'm not sure what provoked somebody to make "tzset()" *not* free up the abbreviation-strings array - which is kind of annoying, given that I'd be willing to bet I'm the person who made it not do so, and seem to remember having done so because some stupid piece of software broke when it *did* free it.... Unfortunately, the pointer to that array is in a structure pointed to by a static pointer. However, *if* you can call "localtime()" on a time that's known to be in a time zone that corresponds to the first abbreviation in the file - possibly easier said than done, although you might try passing it first a pointer to a value of -1, and then a pointer to a value of "-1 plus half a year", and then, for each of the times, if "localtime()" doesn't return a null pointer, save the "tm_zone" values and, if both of them are non-NULL, see which one is lower - you can try doing a "free()" on the "tm_zone" value for that time zone. This is a somewhat disgusting hack, but, well, that's life....

1 0

tzload memory leak?
by eubank＠predict.com April 16, 1993

April 16, 1993

I've been using an application (under SunOS 4.1.3) which switches time zones frequently. It has a memory leak which I think I've tracked down to tzload, which I call via tzset. Since it would hardly be noticeable to anyone who didn't happen to be using (or abusing) tzset thousands of times, I wouldn't be surprised if it hadn't been noticed before. On the off chance that someone out there has encountered it, can you send me pointers to patches, workarounds, etc.? I can't switch to Solaris yet. Here are some details: I profile this code: #include <time.h> main() { int i; for (i=0; i<100; i++) { tzset(); } } and find that malloc is called roughly 400 times, while free is called roughly 300 times. If I increase the number of iterations in the loop tp 1000, the calls to malloc and free go up by a factor of 10. malloc is being called from calloc, which is being called from allocall, which is being called from tzload. It looks to me like tzload allocates 4 things and only frees 3 of them each time it is called. Thanks for any help you can give me. Stephen Eubank eubank(a)predict.com

1 0

FYA
by guy＠auspex.com April 6, 1993

April 6, 1993

Yes, but whose code is it using? :-) From: knauer(a)cs.uiuc.edu (Rob Knauerhase) Newsgroups: rec.humor.funny Subject: Daylight Savings Keywords: topical, smirk Message-ID: <S530.605b(a)looking.on.ca> Date: 6 Apr 93 07:20:02 GMT Organization: Department of Computer Science, Univ. of Illinois @ Urbana My mother didn't know just how smart her new VCR was until she got up this morning and noticed it was flashing: 1:00 1:00 1:00 1:00 1:00... Rob -- Rob Knauerhase, University of Illinois @ Urbana, Dept. of Computer Science "See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs." -- Dave Barry -- Selected by Maddi Hausmann. MAIL your joke (jokes ONLY) to funny(a)clarinet.com. Attribute the joke's source if at all possible. A Daemon will auto-reply. Remember: Only ONE joke per submission. Extra jokes may be rejected.

1 0

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

March 29, 1993

> As a matter of fact, this year, summer time in Israel starts at 3-Apr-93 > till 4-Sep-93. Every year the dates of summer time are decided at that > year and cannot be anticipated. I.e., either Ephraim Silverberg, who contributed the most-recently-seen rules for Israel, as seen in "/usr/share/lib/zoneinfo/asia" in SunOS 4.x and 5.x systems and elsewhere: # From Ephraim Silverberg (April 18, 1989): # Prior to 1989, the rules concerning Daylight Savings Time changed every # year; as information, regarding exact times and dates during this period, # is not readily available at the present time, the rules commence starting # with the year 1989. # From 1989 onwards the rules are as follows: # # 1. Daylight Savings Time commences midnight of the first Saturday night # following the seven-day festival of Pesach (Passover). The transition # is from midnight Israel Standard Time to 1 a.m. Israel Daylight Savings # time. As the Pesach festival is dependent on the Lunar calendar (the # first day is always on the 15th day of the month of Nisan), the rule # changes every year on the Gregorian calendar. # # 2. Standard Time is reinstated on the Saturday night whereupon Jews # following the Ashkenazi (European) rite begin to recite the Selichot # (forgiveness) prayers prior to the Jewish Lunar New Year. The transition # is from midnight Israel Daylight Savings time to 11 p.m. Israel Standard # Time. The law (according to the Ashkenazi custom) concerning the # commencement of the Selichot prayers is described in chapter 128, section # 5 of the "Code of Jewish Law," by Rabbi Shlomo Ganzfried (translated by # Hyman E. Goldin): # # Beginning with the Sunday [**] before Rosh Hashanah [***], # we rise early for the service of Selichot (supplications for # forgiveness). If Rosh Hashanah occurs on Monday or Tuesday, we # begin saying the Selichot from the Sunday of the preceding week. # # This, too, varies from year to year on the Gregorian calendar and, thus, # two explicit timezone rules are required for each Gregorian year. # # [**] actually Saturday night as the Jewish day commences at nightfall. # [***] the Jewish Lunar New Year. was mistaken, or, after he sent that information out, the government went back to changing the rules every year? (Please "Cc:" "tz(a)elsie.nci.nih.gov" on any responses.)

1 0

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

tz92.tar.Z
by ado April 25, 1992

April 25, 1992

By popular demand (well, at any rate, following a request by kre@munnari), the latest versions of time zone source code and data files that I have are available on elsie.nci.nih.gov (128.231.16.1) as ~ftp/pub/tz92.tar.Z. --ado

1 0

australasia
by ado March 19, 1992

March 19, 1992

Attached is what I hope is the final (for spring of 1992 anyway) version of australasia, incorporating lots of good suggestions and information from Bradley White and Robert Elz. The shar file will unpack to two files, "yearistype.sh" and "australasia"--be sure to make an executable version of "yearistype.sh" named "yearistype" before running "zic". On recent-vintage Sun systems, the command make yearistype suffices. The shell script is needed because South Australia now seems to end DST at different times in even and odd years. --ado : To unbundle, sh this file echo file 'yearistype.sh' >&2 cat >'yearistype.sh' <<'End of yearistype.sh' #! /bin/sh : '@(#)yearistype.sh 7.2' case $#-$2 in 2-odd) case $1 in *[13579]) exit 0 ;; *) exit 1 ;; esac ;; 2-even) case $1 in *[24680]) exit 0 ;; *) exit 1 ;; esac ;; 2-*) echo "$0: wild type - $2" >&2 exit 1 ;; *) echo "$0: usage is $0 year type" >&2 exit 1 ;; esac End of yearistype.sh echo file 'australasia' >&2 cat >'australasia' <<'End of australasia' # @(#)australasia 7.13 # Notes are at the end of this file ############################################################################### # Australia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/North 9:30 - CST # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/West 8:00 - WST 1974 Oct lastSun 2:00 8:00 1:00 WST 1975 Mar Sun>=1 3:00 8:00 - WST 1983 Oct lastSun 2:00 8:00 1:00 WST 1984 Mar Sun>=1 3:00 8:00 - WST 1991 Nov 17 2:00 8:00 1:00 WST 1992 Mar Sun>=1 3:00 8:00 - WST # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Queensland 10:00 - EST 1971 Oct lastSun 2:00 10:00 1:00 EST 1972 Feb lastSun 3:00 10:00 - EST 1989 Oct lastSun 2:00 10:00 1:00 EST 1990 Mar Sun>=1 3:00 10:00 - EST 1990 Oct lastSun 2:00 10:00 1:00 EST 1991 Mar Sun>=1 3:00 10:00 - EST 1991 Oct lastSun 2:00 10:00 1:00 EST 1992 Mar Sun>=1 3:00 10:00 - EST # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 max - Oct lastSun 2:00 1:00 - Rule AS 1972 1985 - Mar Sun>=1 3:00 0 - Rule AS 1986 1989 - Mar Sun>=15 3:00 0 - Rule AS 1990 max even Mar Sun>=22 3:00 0 - Rule AS 1990 max odd Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/South 9:30 AS CST # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AT 1967 only - Oct 1 2:00 1:00 - Rule AT 1968 only - Mar 31 3:00 0 - Rule AT 1968 1985 - Oct lastSun 2:00 1:00 - Rule AT 1969 1971 - Mar Sun>=8 3:00 0 - Rule AT 1972 only - Feb 27 3:00 0 - Rule AT 1973 1981 - Mar Sun>=1 3:00 0 - Rule AT 1982 1983 - Mar lastSun 3:00 0 - Rule AT 1984 1986 - Mar Sun>=1 3:00 0 - Rule AT 1986 only - Oct 19 2:00 1:00 - Rule AT 1987 1990 - Mar Sun>=15 3:00 0 - Rule AT 1987 only - Oct 25 2:00 1:00 - Rule AT 1988 1990 - Oct lastSun 2:00 1:00 - Rule AT 1991 max - Oct Sun>=1 2:00 1:00 - Rule AT 1991 max - Mar lastSun 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Tasmania 10:00 AT EST # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AV 1971 1985 - Oct lastSun 2:00 1:00 - Rule AV 1972 only - Feb 27 3:00 0 - Rule AV 1973 1985 - Mar Sun>=1 3:00 0 - Rule AV 1986 1990 - Mar Sun>=15 3:00 0 - Rule AV 1986 1987 - Oct Sun>=15 2:00 1:00 - Rule AV 1988 max - Oct lastSun 2:00 1:00 - Rule AV 1991 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Victoria 10:00 AV EST # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AN 1971 1985 - Oct lastSun 2:00 1:00 - Rule AN 1972 only - Feb 27 3:00 0 - Rule AN 1973 1981 - Mar Sun>=1 3:00 0 - Rule AN 1982 only - Apr 4 3:00 0 - Rule AN 1983 1985 - Mar Sun>=1 3:00 0 - Rule AN 1986 only - Mar 16 3:00 0 - Rule AN 1986 only - Oct 19 2:00 1:00 - Rule AN 1987 only - Mar 15 3:00 0 - Rule AN 1987 max - Oct lastSun 2:00 1:00 - # Rule AN 1988 only - Mar Sun>=1 3:00 0 - # Rule AN 1989 only - Mar Sun>=15 3:00 0 - Rule AN 1988 1989 - Mar Sun>=15 3:00 0 - # Rule AN 1990 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/NSW 10:00 AN EST Zone Australia/Yancowinna 9:30 AN CST Zone Australia/LHI 10:30 AN ??? Link Australia/NSW Australia/ACT # Australian Capital Territory ############################################################################### # New Zealand # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NZ 1974 1988 - Oct lastSun 2:00 1:00 D # Rule NZ 1989 max - Oct Sun>=1 2:00 1:00 D Rule NZ 1989 only - Oct 8 2:00 1:00 D # Rule NZ 1990 max - Oct Sun>=1 2:00 1:00 D # Rule NZ 1975 1989 - Mar Sun>=1 3:00 0 S Rule NZ 1990 max - Mar Sun>=15 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone NZ 12:00 NZ NZ%sT # New Zealand Zone NZ-CHAT 12:45 - NZ-CHAT # Chatham Island ############################################################################### # NOTES ############################################################################### # Australia # From John Mackin (March 6, 1991): # We in Australia have _never_ referred to DST as `daylight' time. # It is called `summer' time. Now by a happy coincidence, `summer' # and `standard' happen to start with the same letter; hence, the # abbreviation does _not_ change... # The legislation does not actually define abbreviations, at least # in this State, but the abbreviation is just commonly taken to be the # initials of the phrase, and the legislation here uniformly uses # the phrase `summer time' and does not use the phrase `daylight # time'. # Announcers on the Commonwealth radio network, the ABC (for Australian # Broadcasting Commission), use the phrases `Eastern Standard Time' # or `Eastern Summer Time'. (Note, though, that as I say in the # current australasia file, there is really no such thing.) Announcers # on its overseas service, Radio Australia, use the same phrases # prefixed by the word `Australian' when referring to local times; # time announcements on that service, naturally enough, are made in UTC. # From Arthur David Olson (March 8 1992): # Given the above, what's chosen for year-round use is: # CST for any place operating at a GMTOFF of 9:30 # WST for any place operating at a GMTOFF of 8:00 # EST for any place operating at a GMTOFF of 10:00 # Australia/North # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The NORTHERN TERRITORY.. [ Courtesy N.T. Dept of the Chief Minister ] # # [ Nov 1990 ] # # N.T. have never utilised any DST due to sub-tropical/tropical location. # ... # Zone Australia/North 9:30 - CST # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # the Northern Territory do[es] not have daylight saving. # Australia/West # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of WESTERN AUSTRALIA.. [ Courtesy W.A. dept Premier+Cabinet ] # # [ Nov 1990 ] # # W.A. suffers from a great deal of public and political opposition to # # DST in principle. A bill is brought before parliament in most years, but # # usually defeated either in the upper house, or in party caucus # # before reaching parliament. # ... # Zone Australia/West 8:00 AW %sST # ... # Rule AW 1974 only - Oct lastSun 2:00 1:00 D # Rule AW 1975 only - Mar Sun>=1 3:00 0 W # Rule AW 1983 only - Oct lastSun 2:00 1:00 D # Rule AW 1984 only - Mar Sun>=1 3:00 0 W # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # Western Australia...do[es] not have daylight saving. # From John D. Newman via Bradley White (November 2, 1991): # Western Australia is still on "winter time". Some DH in Sydney # rang me at home a few days ago at 6.00am. (He had just arrived at # work at 9.00am.) # W.A. is switching to Summer Time on Nov 17th just to confuse # everybody again. # From Arthur David Olson (March 8, 1992): # The 1992 ending date used in the rules is a best guess; # it matches what was used in the past. # Australia/Queensland # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of QUEENSLAND.. [ Courtesy Qld. Dept Premier Econ&Trade Devel ] # # [ Dec 1990 ] # ... # Zone Australia/Queensland 10:00 AQ %sST # ... # Rule AQ 1971 only - Oct lastSun 2:00 1:00 D # Rule AQ 1972 only - Feb lastSun 3:00 0 E # Rule AQ 1989 max - Oct lastSun 2:00 1:00 D # Rule AQ 1990 max - Mar Sun>=1 3:00 0 E # From Bradley White (December 24, 1989): # "Australia/Queensland" now observes daylight time (i.e. from # October 1989). # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Queensland...[has] agreed to end daylight saving # at 3am tomorrow (March 3)... # From John Mackin (March 6, 1991): # I can certainly confirm for my part that Daylight Saving in NSW did in fact # end on Sunday, 3 March. I don't know at what hour, though. (It surprised # me.) # From Bradley White (March 8, 1992): # ...there was recently a referendum in Queensland which resulted # in the experimental daylight saving system being abandoned. So, ... # ... # Rule QLD 1989 1991 - Oct lastSun 2:00 1:00 D # Rule QLD 1990 1992 - Mar Sun>=1 3:00 0 S # ... # From Arthur David Olson (March 8, 1992): # The chosen rules the union of the 1971/1972 change and the 1989-1992 changes. # Australia/Tasmania, Australia/South, and Australia/Victoria # From Arthur David Olson (March 8, 1992): # The rules from version 7.1 follow. # There are lots of differences between these rules and # the Shepherd et al. rules. Since the Shepherd et al. rules # and Bradley White's newspaper article are in agreement on # current DST ending dates, no worries. # # Rule Oz 1971 1985 - Oct lastSun 2:00 1:00 - # Rule Oz 1986 max - Oct Sun<=24 2:00 1:00 - # Rule Oz 1972 only - Feb 27 3:00 0 - # Rule Oz 1973 1986 - Mar Sun>=1 3:00 0 - # Rule Oz 1987 max - Mar Sun<=21 3:00 0 - # Zone Australia/Tasmania 10:00 Oz EST # Zone Australia/South 9:30 Oz CST # Zone Australia/Victoria 10:00 Oz EST 1985 Oct lastSun 2:00 # 10:00 1:00 EST 1986 Mar Sun<=21 3:00 # 10:00 Oz EST # From Robert Elz (March 6, 1991): # I believe that the current start date for DST is "lastSun" in Oct... # that changed Oct 89. That is, we're back to the # original rule, and that rule currently applies in all the states # that have dst, incl Qld. (Certainly it was true in Vic). # The file I'm including says that happened in 1988, I think # that's incorrect, but I'm not 100% certain. # Australia/South # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...South Australia...[has] agreed to end daylight saving # at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of SOUTH AUSTRALIA....[ Courtesy of S.A. Dept of Labour ] # # [ Nov 1990 ] # ... # Zone Australia/South 9:30 AS %sST # ... # Rule AS 1971 max - Oct lastSun 2:00 1:00 D # Rule AS 1972 1985 - Mar Sun>=1 3:00 0 C # Rule AS 1986 1990 - Mar Sun<=21 3:00 0 C # Rule AS 1991 max - Mar Sun>=1 3:00 0 C # From Bradley White (March 11, 1992): # Recent correspondence with a friend in Adelaide # contained the following exchange: "Due to the Adelaide Festival, # South Australia delays setting back our clocks for a few weeks." # From Robert Elz (March 13, 1992): # I heard that apparently (or at least, it appears that) # South Aus will have an extra 3 weeks daylight saving every even # numbered year (from 1990). That's when the Adelaide Festival # is on... # Australia/Tasmania # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Tasmania will revert to Australian Eastern Standard Time on March 31... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of TASMANIA.. [Courtesy Tasmanian Dept of Premier + Cabinet ] # # [ Nov 1990 ] # ... # Zone Australia/Tasmania 10:00 AT %sST # ... # Rule AT 1967 only - Oct Sun>=1 2:00 1:00 D # Rule AT 1968 only - Mar lastSun 3:00 0 E # Rule AT 1968 1985 - Oct lastSun 2:00 1:00 D # Rule AT 1969 1971 - Mar Sun>=8 3:00 0 E # Rule AT 1972 only - Feb lastSun 3:00 0 E # Rule AT 1973 1981 - Mar Sun>=1 3:00 0 E # Rule AT 1982 1983 - Mar lastSun 3:00 0 E # Rule AT 1984 1986 - Mar Sun>=1 3:00 0 E # Rule AT 1986 only - Oct Sun>=15 2:00 1:00 D # Rule AT 1987 1990 - Mar Sun>=15 3:00 0 E # Rule AT 1987 only - Oct Sun>=22 2:00 1:00 D # Rule AT 1988 1990 - Oct lastSun 2:00 1:00 D # Rule AT 1991 max - Oct Sun>=1 2:00 1:00 D # Rule AT 1991 max - Mar lastSun 3:00 0 E # From Bill Hart via Alexander Dupuy and Guy Harris (October 10, 1991): # My state Government in there eagerness to get a few more bucks for the # tourist industry industry decided to change the daylight savings times # yet again (we now have almost 6 months per year)... # ... # Rule Oz 1986 1990 - Oct Sun<=24 2:00 1:00 - # Rule Oz 1991 max - Oct Sun>=1 2:00 1:00 - # ... # Rule Oz 1987 1990 - Mar Sun<=21 3:00 0 - # Rule Oz 1991 max - Mar Sun<=31 3:00 0 - # From Bill Hart via Guy Harris (October 10, 1991): # Oh yes, the new daylight savings rules are uniquely tasmanian, we have # 6 weeks a year now when we are out of sync with the rest of Australia # (but nothing new about that). # Australia/Victoria # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Victoria...[has] agreed to end daylight saving at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of VICTORIA.. [ Courtesy of Vic. Dept of Premier + Cabinet ] # # [ Nov 1990 ] # ... # Zone Australia/Victoria 10:00 AV %sST # ... # Rule AV 1971 1985 - Oct lastSun 2:00 1:00 D # Rule AV 1972 only - Feb lastSun 3:00 0 E # Rule AV 1973 1985 - Mar Sun>=1 3:00 0 E # Rule AV 1986 1990 - Mar Sun>=15 3:00 0 E # Rule AV 1986 1987 - Oct Sun>=15 2:00 1:00 D # Rule AV 1988 max - Oct lastSun 2:00 1:00 D # Rule AV 1991 max - Mar Sun>=1 3:00 0 E # Australia/NSW # From Arthur David Olson: # New South Wales and subjurisdictions have their own ideas of a fun time. # Based on law library research by John Mackin (john(a)basser.cs.su.oz) # who notes: # In Australia, time is not legislated federally, but rather by the # individual states. Thus, while such terms as ``Eastern Standard Time'' # [I mean, of course, Australian EST, not any other kind] are in common # use, _they have NO REAL MEANING_, as they are not defined in the # legislation. This is very important to understand. # I have researched New South Wales time only... # From Dave Davey (March 3, 1990): # Rule NSW 1988 only - Mar Sun>=1 3:00 0 - # Rule NSW 1989 only - Mar Sun<=21 3:00 0 - # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # NSW...[has] agreed to end daylight saving at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of NEW SOUTH WALES.. [confirmed by Attorney General's Dept N.S.W] # # [ Dec 1990 ] # ... # Rule AN 1988 1989 - Mar Sun<=21 3:00 0 E # ... # From John Mackin (March 9, 1991) # I have confirmed the accuracy of the historical data for NSW in the # file Robert forwarded # From Arthur David Olson (March 8, 1992): # Sources differ on whether DST ended March 6 or March 20 in 1988; # March 20 (the "confirmed" date) is in the chosen rules. # Australia/Yancowinna # From John Basser (January 4, 1989): # `Broken Hill' means the County of Yancowinna. # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # YANCOWINNA.. [ Confirmation courtesy of Broken Hill Postmaster ] # # [ Dec 1990 ] # ... # # Yancowinna uses Central Standard Time, despite it's location on the # # New South Wales side of the S.A. border. Most business and social dealings # # are with CST zones, therefore CST is legislated by local government # # although the switch to Summer Time occurs in line with N.S.W. There have # # been years when this did not apply, but the historical data is not # # presently available. # Zone Australia/Yancowinna 9:30 AY %sST # ... # Rule AY 1971 1985 - Oct lastSun 2:00 1:00 D # Rule AY 1972 only - Feb lastSun 3:00 0 C # [followed by other Rules] # Australia/LHI # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # LHI... [ Courtesy of Pauline Van Winsen.. pauline@Aus ] # [ Dec 1990 ] # Lord Howe Island is located off the New South Wales coast, and is half an # hour ahead of NSW time. ############################################################################### # New Zealand, from Elz' asia 1.1 # Elz says "no guarantees" # From Mark Davies (October 3, 1990): # the 1989/90 year was a trial of an extended "daylight saving" period. # This trial was deemed successful and the extended period adopted for # subsequent years (with the addition of a further week at the start). # source -- phone call to Ministry of Internal Affairs Head Office. # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The Country of New Zealand (Australia's east island -) Gee they hate that! # # or is Australia the west island of N.Z. # # [ courtesy of Geoff Tribble.. Geofft@Aus.. Auckland N.Z. ] # # [ Nov 1990 ] # ... # Rule NZ 1974 1988 - Oct lastSun 2:00 1:00 D # Rule NZ 1989 max - Oct Sun>=1 2:00 1:00 D # Rule NZ 1975 1989 - Mar Sun>=1 3:00 0 S # Rule NZ 1990 max - Mar lastSun 3:00 0 S # ... # Zone NZ 12:00 NZ NZ%sT # New Zealand # Zone NZ-CHAT 12:45 - NZ-CHAT # Chatham Island # From Arthur David Olson (March 8, 1992): # The chosen rules use the Davies October 8 values for the start of DST in 1989 # rather than the October 1 value. End of australasia exit

1 0

Re: australasia
by ado March 12, 1992

March 12, 1992

> It was difficult to find the actual rules! I know this is probably > one of your prime motivations in trying to clean it up, but running > it through (the equivalent of) "sed /^#/d | cat -s" made things much > easier for a human to parse. (So much for the bogus comment.) Would moving rules to the front of the file and comments to the back of the file address this concern? --ado

2 1

australasia
by ado March 11, 1992

March 11, 1992

Prodded by a note from Bradley White on Queensland abandoning DST, after a review of the last year-and-a-half's worth of correspondence, and having mulled things over in the bathtub, the attached is the best I can do on what Australasia is like at the moment. There's something here to offend everyone; I'm eager for suggestions. --ado : To unbundle, sh this file echo file 'australasia' >&2 cat >'australasia' <<'End of australasia' # @(#)australasia 7.8 ############################################################################### # Australia # From John Mackin (March 6, 1991): # We in Australia have _never_ referred to DST as `daylight' time. # It is called `summer' time. Now by a happy coincidence, `summer' # and `standard' happen to start with the same letter; hence, the # abbreviation does _not_ change... # The legislation does not actually define abbreviations, at least # in this State, but the abbreviation is just commonly taken to be the # initials of the phrase, and the legislation here uniformly uses # the phrase `summer time' and does not use the phrase `daylight # time'. # Announcers on the Commonwealth radio network, the ABC (for Australian # Broadcasting Commission), use the phrases `Eastern Standard Time' # or `Eastern Summer Time'. (Note, though, that as I say in the # current australasia file, there is really no such thing.) Announcers # on its overseas service, Radio Australia, use the same phrases # prefixed by the word `Australian' when referring to local times; # time announcements on that service, naturally enough, are made in UTC. # From Arthur David Olson (March 8 1992): # Given the above, what's used below year-round is: # CST for any place operating at a GMTOFF of 9:30 # WST for any place operating at a GMTOFF of 8:00 # EST for any place operating at a GMTOFF of 10:00 # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The NORTHERN TERRITORY.. [ Courtesy N.T. Dept of the Chief Minister ] # # [ Nov 1990 ] # # N.T. have never utilised any DST due to sub-tropical/tropical location. # ... # Zone Australia/North 9:30 - CST # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # the Northern Territory do[es] not have daylight saving. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/North 9:30 - CST # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of WESTERN AUSTRALIA.. [ Courtesy W.A. dept Premier+Cabinet ] # # [ Nov 1990 ] # # W.A. suffers from a great deal of public and political opposition to # # DST in principle. A bill is brought before parliament in most years, but # # usually defeated either in the upper house, or in party caucus # # before reaching parliament. # ... # Zone Australia/West 8:00 AW %sST # ... # Rule AW 1974 only - Oct lastSun 2:00 1:00 D # Rule AW 1975 only - Mar Sun>=1 3:00 0 W # Rule AW 1983 only - Oct lastSun 2:00 1:00 D # Rule AW 1984 only - Mar Sun>=1 3:00 0 W # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # Western Australia...do[es] not have daylight saving. # From John D. Newman via Bradley White (November 2, 1991): # Western Australia is still on "winter time". Some DH in Sydney # rang me at home a few days ago at 6.00am. (He had just arrived at # work at 9.00am.) # W.A. is switching to Summer Time on Nov 17th just to confuse # everybody again. # From Arthur David Olson (March 8, 1992): # The 1992 ending date below is a best guess; # it matches what was used in the past. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/West 8:00 - WST 1974 Oct lastSun 2:00 8:00 1:00 WST 1975 Mar Sun>=1 3:00 8:00 - WST 1983 Oct lastSun 2:00 8:00 1:00 WST 1984 Mar Sun>=1 3:00 8:00 - WST 1991 Nov 17 2:00 8:00 1:00 WST 1992 Mar Sun>=1 3:00 8:00 - WST # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of QUEENSLAND.. [ Courtesy Qld. Dept Premier Econ&Trade Devel ] # # [ Dec 1990 ] # ... # Zone Australia/Queensland 10:00 AQ %sST # ... # Rule AQ 1971 only - Oct lastSun 2:00 1:00 D # Rule AQ 1972 only - Feb lastSun 3:00 0 E # Rule AQ 1989 max - Oct lastSun 2:00 1:00 D # Rule AQ 1990 max - Mar Sun>=1 3:00 0 E # From Bradley White (December 24, 1989): # "Australia/Queensland" now observes daylight time (i.e. from # October 1989). # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Queensland...[has] agreed to end daylight saving # at 3am tomorrow (March 3)... # From John Mackin (March 6, 1991): # I can certainly confirm for my part that Daylight Saving in NSW did in fact # end on Sunday, 3 March. I don't know at what hour, though. (It surprised # me.) # From Bradley White (March 8, 1992): # ...there was recently a referendum in Queensland which resulted # in the experimental daylight saving system being abandoned. So, ... # ... # Rule QLD 1989 1991 - Oct lastSun 2:00 1:00 D # Rule QLD 1990 1992 - Mar Sun>=1 3:00 0 S # ... # From Arthur David Olson (March 8, 1992): # Here is the union of the 1971/1972 change and the 1989-1992 changes. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Queensland 10:00 - EST 1971 Oct lastSun 2:00 10:00 1:00 EST 1972 Feb lastSun 3:00 10:00 - EST 1989 Oct lastSun 2:00 10:00 1:00 EST 1990 Mar Sun>=1 3:00 10:00 - EST 1990 Oct lastSun 2:00 10:00 1:00 EST 1991 Mar Sun>=1 3:00 10:00 - EST 1991 Oct lastSun 2:00 10:00 1:00 EST 1992 Mar Sun>=1 3:00 10:00 - EST # From Arthur David Olson (March 8, 1992): # The rules from version 7.1 follow. # There are lots of differences between these rules and # the Shepherd et al. rules. Since the Shepherd et al. rules # and Bradley White's newspaper article are in agreement on # current DST ending dates, no worries. # # Rule Oz 1971 1985 - Oct lastSun 2:00 1:00 - # Rule Oz 1986 max - Oct Sun<=24 2:00 1:00 - # Rule Oz 1972 only - Feb 27 3:00 0 - # Rule Oz 1973 1986 - Mar Sun>=1 3:00 0 - # Rule Oz 1987 max - Mar Sun<=21 3:00 0 - # Zone Australia/Tasmania 10:00 Oz EST # Zone Australia/South 9:30 Oz CST # Zone Australia/Victoria 10:00 Oz EST 1985 Oct lastSun 2:00 # 10:00 1:00 EST 1986 Mar Sun<=21 3:00 # 10:00 Oz EST # From Robert Elz (March 6, 1991): # I believe that the current start date for DST is "lastSun" in Oct... # that changed Oct 89. That is, we're back to the # original rule, and that rule currently applies in all the states # that have dst, incl Qld. (Certainly it was true in Vic). # The file I'm including says that happened in 1988, I think # that's incorrect, but I'm not 100% certain. # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...South Australia...[has] agreed to end daylight saving # at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of SOUTH AUSTRALIA....[ Courtesy of S.A. Dept of Labour ] # # [ Nov 1990 ] # ... # Zone Australia/South 9:30 AS %sST # ... # Rule AS 1971 max - Oct lastSun 2:00 1:00 D # Rule AS 1972 1985 - Mar Sun>=1 3:00 0 C # Rule AS 1986 1990 - Mar Sun<=21 3:00 0 C # Rule AS 1991 max - Mar Sun>=1 3:00 0 C # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 max - Oct lastSun 2:00 1:00 - Rule AS 1972 1985 - Mar Sun>=1 3:00 0 - Rule AS 1986 1990 - Mar Sun<=21 3:00 0 - Rule AS 1991 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/South 9:30 AS CST # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Tasmania will revert to Australian Eastern Standard Time on March 31... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of TASMANIA.. [Courtesy Tasmanian Dept of Premier + Cabinet ] # # [ Nov 1990 ] # ... # Zone Australia/Tasmania 10:00 AT %sST # ... # Rule AT 1967 only - Oct Sun>=1 2:00 1:00 D # Rule AT 1968 only - Mar lastSun 3:00 0 E # Rule AT 1968 1985 - Oct lastSun 2:00 1:00 D # Rule AT 1969 1971 - Mar Sun>=8 3:00 0 E # Rule AT 1972 only - Feb lastSun 3:00 0 E # Rule AT 1973 1981 - Mar Sun>=1 3:00 0 E # Rule AT 1982 1983 - Mar lastSun 3:00 0 E # Rule AT 1984 1986 - Mar Sun>=1 3:00 0 E # Rule AT 1986 only - Oct Sun>=15 2:00 1:00 D # Rule AT 1987 1990 - Mar Sun>=15 3:00 0 E # Rule AT 1987 only - Oct Sun>=22 2:00 1:00 D # Rule AT 1988 1990 - Oct lastSun 2:00 1:00 D # Rule AT 1991 max - Oct Sun>=1 2:00 1:00 D # Rule AT 1991 max - Mar lastSun 3:00 0 E # From Bill Hart via Alexander Dupuy and Guy Harris (October 10, 1991): # My state Government in there eagerness to get a few more bucks for the # tourist industry industry decided to change the daylight savings times # yet again (we now have almost 6 months per year)... # ... # Rule Oz 1986 1990 - Oct Sun<=24 2:00 1:00 - # Rule Oz 1991 max - Oct Sun>=1 2:00 1:00 - # ... # Rule Oz 1987 1990 - Mar Sun<=21 3:00 0 - # Rule Oz 1991 max - Mar Sun<=31 3:00 0 - # From Bill Hart via Guy Harris (October 10, 1991): # Oh yes, the new daylight savings rules are uniquely tasmanian, we have # 6 weeks a year now when we are out of sync with the rest of Australia # (but nothing new about that). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AT 1967 only - Oct Sun>=1 2:00 1:00 - Rule AT 1968 only - Mar lastSun 3:00 0 - Rule AT 1968 1985 - Oct lastSun 2:00 1:00 - Rule AT 1969 1971 - Mar Sun>=8 3:00 0 - Rule AT 1972 only - Feb lastSun 3:00 0 - Rule AT 1973 1981 - Mar Sun>=1 3:00 0 - Rule AT 1982 1983 - Mar lastSun 3:00 0 - Rule AT 1984 1986 - Mar Sun>=1 3:00 0 - Rule AT 1986 only - Oct Sun>=15 2:00 1:00 - Rule AT 1987 1990 - Mar Sun>=15 3:00 0 - Rule AT 1987 only - Oct Sun>=22 2:00 1:00 - Rule AT 1988 1990 - Oct lastSun 2:00 1:00 - Rule AT 1991 max - Oct Sun>=1 2:00 1:00 - Rule AT 1991 max - Mar lastSun 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Tasmania 10:00 AT EST # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # ...Victoria...[has] agreed to end daylight saving at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of VICTORIA.. [ Courtesy of Vic. Dept of Premier + Cabinet ] # # [ Nov 1990 ] # ... # Zone Australia/Victoria 10:00 AV %sST # ... # Rule AV 1971 1985 - Oct lastSun 2:00 1:00 D # Rule AV 1972 only - Feb lastSun 3:00 0 E # Rule AV 1973 1985 - Mar Sun>=1 3:00 0 E # Rule AV 1986 1990 - Mar Sun>=15 3:00 0 E # Rule AV 1986 1987 - Oct Sun>=15 2:00 1:00 D # Rule AV 1988 max - Oct lastSun 2:00 1:00 D # Rule AV 1991 max - Mar Sun>=1 3:00 0 E # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AV 1971 1985 - Oct lastSun 2:00 1:00 - Rule AV 1972 only - Feb lastSun 3:00 0 - Rule AV 1973 1985 - Mar Sun>=1 3:00 0 - Rule AV 1986 1990 - Mar Sun>=15 3:00 0 - Rule AV 1986 1987 - Oct Sun>=15 2:00 1:00 - Rule AV 1988 max - Oct lastSun 2:00 1:00 - Rule AV 1991 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Victoria 10:00 AV EST # From Arthur David Olson: # New South Wales and subjurisdictions have their own ideas of a fun time. # Based on law library research by John Mackin (john(a)basser.cs.su.oz) # who notes: # In Australia, time is not legislated federally, but rather by the # individual states. Thus, while such terms as ``Eastern Standard Time'' # [I mean, of course, Australian EST, not any other kind] are in common # use, _they have NO REAL MEANING_, as they are not defined in the # legislation. This is very important to understand. # I have researched New South Wales time only... # From Dave Davey (March 3, 1990): # Rule NSW 1988 only - Mar Sun>=1 3:00 0 - # Rule NSW 1989 only - Mar Sun<=21 3:00 0 - # From Bradley White (March 4, 1991): # A recent excerpt from an Australian newspaper... # NSW...[has] agreed to end daylight saving at 3am tomorrow (March 3)... # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The state of NEW SOUTH WALES.. [confirmed by Attorney General's Dept N.S.W] # # [ Dec 1990 ] # ... # Rule AN 1988 1989 - Mar Sun<=21 3:00 0 E # ... # From John Mackin (March 9, 1991) # I have confirmed the accuracy of the historical data for NSW in the # file Robert forwarded # From Arthur David Olson (March 8, 1992): # Sources differ on whether DST ended March 6 or March 20 in 1988; # March 20 (the "confirmed" date) is used below. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NSW 1971 1985 - Oct lastSun 2:00 1:00 - Rule NSW 1972 only - Feb lastSun 3:00 0 - Rule NSW 1973 1981 - Mar Sun>=1 3:00 0 - Rule NSW 1982 only - Apr 4 3:00 0 - Rule NSW 1983 1985 - Mar Sun>=1 3:00 0 - Rule NSW 1986 only - Mar 16 3:00 0 - Rule NSW 1986 only - Oct 19 2:00 1:00 - Rule NSW 1987 only - Mar 15 3:00 0 - Rule NSW 1987 max - Oct lastSun 2:00 1:00 - # Rule NSW 1988 only - Mar Sun>=1 3:00 0 - # Rule NSW 1989 only - Mar Sun<=21 3:00 0 - Rule NSW 1988 1989 - Mar Sun<=21 3:00 0 - # Rule NSW 1990 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/NSW 10:00 NSW EST # From John Basser (January 4, 1989): # `Broken Hill' means the County of Yancowinna. # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # YANCOWINNA.. [ Confirmation courtesy of Broken Hill Postmaster ] # # [ Dec 1990 ] # ... # # Yancowinna uses Central Standard Time, despite it's location on the # # New South Wales side of the S.A. border. Most business and social dealings # # are with CST zones, therefore CST is legislated by local government # # although the switch to Summer Time occurs in line with N.S.W. There have # # been years when this did not apply, but the historical data is not # # presently available. # Zone Australia/Yancowinna 9:30 AY %sST # ... # Rule AY 1971 1985 - Oct lastSun 2:00 1:00 D # Rule AY 1972 only - Feb lastSun 3:00 0 C # [followed by other Rules] Zone Australia/Yancowinna 9:30 NSW CST # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # LHI... [ Courtesy of Pauline Van Winsen.. pauline@Aus ] # [ Dec 1990 ] # Lord Howe Island is located off the New South Wales coast, and is half an # hour ahead of NSW time. Zone Australia/LHI 10:30 NSW ??? ############################################################################### # New Zealand # New Zealand, from Elz' asia 1.1 # Elz says "no guarantees" # From Mark Davies (October 3, 1990): # the 1989/90 year was a trial of an extended "daylight saving" period. # This trial was deemed successful and the extended period adopted for # subsequent years (with the addition of a further week at the start). # source -- phone call to Ministry of Internal Affairs Head Office. # From George Shepherd via Simon Woodhead via Robert Elz (March 6, 1991): # # The Country of New Zealand (Australia's east island -) Gee they hate that! # # or is Australia the west island of N.Z. # # [ courtesy of Geoff Tribble.. Geofft@Aus.. Auckland N.Z. ] # # [ Nov 1990 ] # ... # Rule NZ 1974 1988 - Oct lastSun 2:00 1:00 D # Rule NZ 1989 max - Oct Sun>=1 2:00 1:00 D # Rule NZ 1975 1989 - Mar Sun>=1 3:00 0 S # Rule NZ 1990 max - Mar lastSun 3:00 0 S # ... # Zone NZ 12:00 NZ NZ%sT # New Zealand # Zone NZ-CHAT 12:45 - NZ-CHAT # Chatham Island # From Arthur David Olson (March 8, 1992): # The below uses the Davies October 8 values for the start of DST in 1989 # rather than the October 1 value. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NZ 1974 1988 - Oct lastSun 2:00 1:00 D # Rule NZ 1989 max - Oct Sun>=1 2:00 1:00 D Rule NZ 1989 only - Oct 8 2:00 1:00 D # Rule NZ 1990 max - Oct Sun>=1 2:00 1:00 D # Rule NZ 1975 1989 - Mar Sun>=1 3:00 0 S Rule NZ 1990 max - Mar Sun>=15 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone NZ 12:00 NZ NZ%sT # New Zealand Zone NZ-CHAT 12:45 - NZ-CHAT # Chatham Island End of australasia exit

2 1

updated leapseconds file
by ado March 2, 1992

March 2, 1992

The attached reflects the leap in June, 1992 (as noted in a 2/24/1992 item from the U. S. Naval Observatory). --ado : To unbundle, sh this file echo file 'leapseconds' >&2 cat >'leapseconds' <<'End of leapseconds' # @(#)leapseconds 7.4 # Allowance for leapseconds added to each timezone file. # 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 End of leapseconds exit

1 0

time zone abbreviations (forwarded from abe@mace.cc.purdue.edu)
by ado Feb. 13, 1992

Feb. 13, 1992

> From abe(a)mace.cc.purdue.edu Wed Feb 12 08:52:04 1992 > ... > Message-Id: <9202121351.AA19535(a)mace.cc.purdue.edu> > To: ado(a)elsie.nci.nih.gov > Subject: time zone mailing list > ... > Paul Eggert (eggert(a)twinsun.com) has informed me that you manage a time > zone mailing list. I would like to be added to it. > > Paul and I have corresponded over the last year about a list of currently > used time zone abbreviations that I maintain. I'm attaching it, in case > you or the readers of your mailing list might be interested in it. Some > of its entries are controversial, as Paul can attest. :-) > > The list grew out of a local need for a function that would convert dates > and times in mail headers to seconds since the Unix epoch. I would be > happy to share that code, too, if there is interest. > > Thanks, > > Vic Abell (abe(a)mace.cc.purdue.edu) > > > > Fri Jan 3 08:10:40 EST 1992 > > Zone GMT + Description > > ACDT 10:30 Australian Central Daylight > ACST 9:30 Australian Central Standard > ADT -3:00 Atlantic Daylight > AEDT 11:00 Australian Eastern Daylight > AES 10:00 Australian Eastern Standard > AEST 10:00 Australian Eastern Standard > AHDT -9:00 Alaska-Hawaii Daylight (1967 to 1983) > AHST -10:00 Alaska-Hawaii Standard (1967 to 1983) > AKDT -8:00 Alaska Daylight > AKST -9:00 Alaska Standard > AST -4:00 Atlantic Standard > AT -2:00 Azores (obsolete) > AWDT 9:00 Australian Western Daylight > AWST 8:00 Australian Western Standard > BRA -3:00 Brazil > BST 1:00 British Summer > BST -3:00 Brazil Standard > BST -11:00 Bering Summer (1967 to 1983) > BT 3:00 Baghdad > BT -11:00 Bering (until 1967) > CADT 10:30 Central Australian Daylight > CAST 9:30 Central Australian Standard > CAT -10:00 Central Alaskan Standard (until 1967) > CCT 8:00 China Coast (obsolete) > CDT 9:00 China Daylight > CDT -5:00 Central Daylight > CEST 2:00 Central European Summer > CET 1:00 Central European > CET DST 2:00 Central European Daylight > CETDST 2:00 Central European Daylight > CST 8:00 China Standard > CST 9:30 North/South Australian Central Standard > CST -6:00 Central Standard > DNT 1:00 Dansk Normal > DST 2:00 Dansk Summer > EAST 10:00 East Australian Standard > EDT -4:00 Eastern Daylight > EEST 3:00 Eastern European Summer > EET 2:00 Eastern European > EET DST 3:00 Eastern European Daylight > EETDST 3:00 Eastern European Daylight > EMT 1:00 Norway > EST -5:00 Eastern Standard > EST 10:00 Australian Eastern Standard > FDT -1:00 Fernando de Noronha Daylight > FST 2:00 French Summer > FST -2:00 Fernando de Noronha Standard > FWT 1:00 French Winter > GMT 0:00 Greenwich > GST -3:00 Greenland Standard (obsolete) > GST 10:00 Guam Standard > HADT -9:00 Hawaiian-Aleutian Daylight > HAST -10:00 Hawaiian-Aleutian Standard > HDT -9:30 Hawaiian Daylight (until 1947) > HFE 2:00 Heure Francais d'Ete > HFH 1:00 Heure Francais d'Hiver > HKT 8:00 Hong Kong > HOE 1:00 Spain > HST -10:00 Hawaiian Standard (-10:30 until 1947) > IDLE 12:00 International Dateline, East > IDLW -12:00 International Dateline, West > IDT 3:00 Israeli Daylight > IDT 4:30 Iran Daylight > IST 2:00 Israeli Standard > IST 3:30 Iran Standard > IST 5:30 Indian Standard > IT 3:30 Iran > ITA 1:00 Italy > JST 9:00 Japanese Standard > JT 7:30 Java > KDT 10:00 Korean Daylight > KST 9:00 Korean Standard > LIGT 10:00 Melbourne, Australia > MAL 8:00 Malaysia > MAT 3:00 Turkey > MDT -6:00 Mountain Daylight > MEDST 2:00 Middle European Daylight > MEST 2:00 Middle European Summer > MESZ 2:00 Mittel Europaeische Sommerzeit > MET 1:00 Middle European > MET DST 2:00 Middle European Daylight > METDST 2:00 Middle European Daylight > MEWT 1:00 Middle European Winter > MEX -6:00 Mexico > MEZ 1:00 Mittel Europaeische Zeit > MSD 3:00 Moscow Summer > MSK 2:00 Moscow Winter > MST -7:00 Mountain Standard > MT 8:30 Moluccas (obsolete) > NDT -2:30 Newfoundland Daylight > NFT -3:30 Newfoundland > NOR 1:00 Norway > NST 8:30 North Sumatran (obsolete) > NST -3:30 Newfoundland Standard > NT -11:00 Nome (until 1967) > NZDT 13:00 New Zealand Daylight > NZST 12:00 New Zealand Standard > NZT 12:00 New Zealand > PDT -7:00 Pacific Daylight > PST -8:00 Pacific Standard > SADT 10:30 South Australian Daylight > SAST 9:30 South Australian Standard > SET 1:00 European -- Prague, Vienna > SST 2:00 Swedish Summer > SST 7:00 South Sumatran (obsolete) > SST 8:00 Singapore Standard > SST -11:00 Samoa Standard > SWT 1:00 Swedish > THA 7:00 Thailand Standard > TST 3:00 Turkish Standard > UT 0:00 Universal > UTC 0:00 Universal Time Coordinated > UTZ -3:00 Western Greenland Standard > VTZ -2:00 Eastern Greenland Standard > VTZ -2:00 Western Greenland Daylight > WADT 9:00 Western Australian Daylight > WAST 8:00 Western Australian Standard > WAT 1:00 West African (obsolete) > WDT 9:00 Western Australian Daylight > WEST 1:00 Western European Summer > WET 0:00 Western European > WET DST 1:00 Western European Daylight > WETDST 1:00 Western European Daylight > WST 8:00 Western Australian Standard > WTZ -1:00 Eastern Greenland Daylight > WUT 1:00 Austria > YDT -8:00 Yukon Daylight > YST -9:00 Yukon Standard

1 0

EEC DST [forwarded from Niels Svennekjaer]
by ado Feb. 10, 1992

Feb. 10, 1992

... From: nrs(a)login.dkuug.dk (Niels Svennekjaer) Message-Id: <9202061007.AA22825(a)login.dkuug.dk> Subject: DST in Denmark To: ado(a)elsie.nci.nih.gov Date: Thu, 6 Feb 92 11:07:36 MET ... Some years ago the EEC decided that it would make a single day to change the DST. The DST is changed the last weekend in March and the last weekend in September, the night between Saturday and Sunday at 2.00 am (02.00). It was decided that it should be tested until (and with) 1992, and then a decision should about continue off the DST. But every one I have talked with didn't know that 1992 was the last year with DST, so I expect that it will continue that way. Hilsen Niels Svennekjaer ... From: nrs(a)login.dkuug.dk (Niels Svennekjaer) Message-Id: <9202100717.AA26347(a)login.dkuug.dk> Subject: Re: DST in Denmark (& EEC countries) To: ado(a)elsie.nci.nih.gov (Arthur David Olson) Date: Mon, 10 Feb 92 8:17:38 MET ... I have just checked with the local EEC office about DST in the EEC countries in Europe. For the years 1990, 1991 & 1992 the DST starts the last weekend in March, and ends in the last weekend in Sep. The only exception is the countries United Kingdom & Ireland, where the government can extend the DST to the last weekend in Oct. (and I think they have done it). But...the EEC has not yet decided to continue with DST after 1992. There has been a lot of talk to terminate the use of DST, but no one knows yet. By the way, the EEC countries are: Denmark; Germany; Holland (The Netherlands); Belgium; Luxemburg; United Kingdom; Ireland; France; Spain; Portugal; Italy; and Greece. You are welcome to use me as reference...

1 0

Washington Post timekeeping observation
by ado Dec. 31, 1991

Dec. 31, 1991

You probably already knew that the Gregorian Adjustment of 1582 added an extra day to every fourth year. What you forgot is that this doesn't apply to the turn-of-the-century years, excpet when they are divisible by 400. If you know this and the "off-sides" rule in hockey, you are a complete human being. December 30, 1991 Washington Post, page D5 --ado

1 0

Starke County, Indiana moves from Central to Eastern
by ado Oct. 28, 1991

Oct. 28, 1991

Yesterday's Washington Post had an article on the switch of Starke County, Indiana from Central to Eastern time; the change is accounted for below. The article runs about twenty column inches of text, and also includes a map of Indiana time zones and a photo of the Hoosiers who duked it out over whether to make the switch. Much of the article is concerned with the political process. --ado SCCS/s.northamerica: 7.1 vs. 7.2 *** 7.1/northamerica Mon Oct 28 16:49:03 1991 --- 7.2/northamerica Mon Oct 28 16:49:04 1991 *************** *** 1,4 **** ! # @(#)northamerica 7.1 ############################################################################### --- 1,4 ---- ! # @(#)northamerica 7.2 ############################################################################### *************** *** 116,121 **** --- 116,127 ---- Zone US/East-Indiana -5:00 US E%sT 1946 -5:00 - EST # Always EST as of 1986 + # From Arthur David Olson (October 28, 1991): + # An article on page A3 of the Sunday, October 27, 1991 Washington Post + # notes that Starke County switched from Central time to Eastern time as of + # October 27, 1991. + Zone US/Indiana-Starke -6:00 US C%sT 1991 Oct 27 2:00 + -5:00 - EST # Always EST as of 1991 Zone US/Arizona -7:00 US M%sT 1946 -7:00 - MST # Always MST as of 1986

1 0

Soviet time zone rule change on 1991/03/31
by ado March 30, 1991

March 30, 1991

The attached from Paul Eggert should be of interest. It looks as if three sets of "Rule" lines for the Soviet Union will be needed; while they should clearly be called SU-Thesis, SU-Antithesis, and SU-Synthesis, which should be which is debatable. --ado > From daemon(a)ncifcrf.gov Sat Mar 23 18:08:44 1991 > Return-Path: <daemon(a)ncifcrf.gov> > Received: from fcs280s.ncifcrf.gov by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA24757; Sat, 23 Mar 91 18:08:41 EST > Received: by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA18877; Sat, 23 Mar 91 18:07:11 EST > Received: from shemp.cs.ucla.edu by fcs280s.ncifcrf.gov (4.1/NCIFCRF-3.0/AWF-2.0) > id AA18874; Sat, 23 Mar 91 18:07:08 EST > Received: by shemp.cs.ucla.edu > (Sendmail 5.61a+YP/2.33) id AA04525; > Sat, 23 Mar 91 15:08:32 -0800 > Received: from yata.UUCP by twinsun.com (4.1/SMI-4.1) > id AA04772; Sat, 23 Mar 91 14:31:41 PST > Received: by yata.mv.la.ca.us (4.1/SMI-4.1) > id AA04965; Sat, 23 Mar 91 13:46:25 PST > Date: Sat, 23 Mar 91 13:46:25 PST > From: yata!eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9103232146.AA04965(a)yata.mv.la.ca.us> > To: ado(a)ncifcrf.gov, buz(a)csd.hku.hk, moraes(a)cs.toronto.edu, rsalz(a)bbn.com > Subject: Soviet time zone rule change on 1991/03/31 (``go to bed as usual'') > Status: RO > > [Is there a mailing list or newsgroup for time zones in software? > Anyway, just to show that the US has no monopoly on time zone screwups, > here's a story from the Los Angeles Times, 1991/03/22, page A18. > Of course they blame it all on Stalin. -- Paul <eggert(a)twinsun.com>] > > > Soviets Get Clocks Back on Track--and It's About Time > > >From Associated Press > > MOSCOW--Red-faced Soviet officials are admitting they haven't kept the > correct time in more than six decades, blaming a mistake in the Stalin > era when clocks should have bene turned back an hour. > > As a result, officials are scrapping the Soviet version of > daylight-saving time this summer. Clocks, however, will still ``fall > back'' an hour in the autumn. > > All this timekeeping havoc is bound to further baffle a nation that has > had its share of confusion for 1991. > > March 31 is when clocks usually are moved forward an hour for summer > time in the Soviet Union, which has 11 time zones. > > But the Council of Ministers has decreed that the move won't be made > for most of the Soviet Union--the huge Russion Federation, which > includes Moscow; Armenia; Azerbaijan; Byelorussia; Turkmenia and the > Ukraine. > > The republics of Estonia, Latvia, Lithuania and Moldova, however, will > follow their rebellious tradition and move their clocks ahead as > before. > > To confound the masses even more, Tadzhikistan, parts of Kazakhstan and > some other regions will actually set their clocks back an hour to > better organize daylight hours, the decree said. > > According to the newspaper Evening Moscow, the move was made to correct > a 61-year-old mistake. > > ``In 1930, it was decided to introduce summer time and move the hands > of clocks one hour ahead,'' the paper said. ``In the passage of time, > they did not announce winter time'' in the fall of 1930, leaving the > country with a single time year-round. > > In 1981, it was decided to restore the seasonal time change. But when > the clocks were moved forward an hour that spring, the country wound up > with two extra hours of sunlight during summer instead of the intended > one. > > Officials figured that the end of March--the regular date to move > clocks ahead--was the best time to correct the imbalance. ``On March > 31, one should not move the hands of the clock ahead, but go to bed as > usual,'' the newspaper advised.

1 0

Re: Dates in Mush
by ado Oct. 15, 1990

Oct. 15, 1990

> Subject: Re: Dates in Mush > > "MET DST" comes from zoneinfo: > ... > Rule M-Eur 1986 max - Mar lastSun 2:00s 1:00 " DST" > Rule M-Eur 1986 max - Sep lastSun 2:00s 0 - > ... > Zone MET 1:00 M-Eur MET%s > ... I've (finally) tracked down the original source of the information, which is attached. --ado > ... > Date: 27 Feb 86 06:03:20 +1100 (Thu) > ... > From: Robert Elz <seismo!munnari!kre> > > ...I believe that the standard timezone names in Europe are "WET" and "WED DST" (with a space)...

1 0

Re: Dates in Mush
by emoryu1!emory!ogicse!cse.ogi.edu!schaefer Sept. 30, 1990

Sept. 30, 1990

On Sep 20, 9:58am, lupe christoph wrote: } Subject: Re: Dates in Mush } } "MET DST" comes from zoneinfo: } } # @(#)europe 1.3 89/02/13 SMI; from Arthur Olson's 3.1 } } ... } Rule M-Eur 1986 max - Mar lastSun 2:00s 1:00 " DST" } Rule M-Eur 1986 max - Sep lastSun 2:00s 0 - } ... } Zone MET 1:00 M-Eur MET%s } ... } } This means that "MET" is suffixed by " DST" in the period "Mar lastSun 2:00s" } till "Sep lastSun 2:00s". Hm. Looks as though something like Rule M-Eur 1986 max - Mar lastSun 2:00s 1:00 S Rule M-Eur 1986 max - Sep lastSun 2:00s 0 - ... Zone MET 1:00 M-Eur ME%sT would produce what B-news (and mush) are expecting for zones. } You might want to ask seismo!elsie!tz about the names. OK, tz is on the To: line. Maybe he (Arthur? Is that you?) could shed some light on the subject. As nearly as I can tell, the B-news parser is prepared to handle arbitrarily mixed cases, periods between the letters, and practically every other combination *except* two words separated by a space. Mush is a less robust about mixed cases and so on because it doesn't expect to be parsing anything but machine-generated date strings. } > Thanks for the info. I think I'm going to try to find a } > better way to parse for it, though. It should be possible } > to recognize it without explicitly reading it into a string, } > e.g. match it literally in the sscanf format or something. } Regular expressions ? Well, actually, what you did isn't too bad in theory but is overkill in all but one of the cases. Even if we do read it into a string, it's not necessary to add a new sscanf call every time; just add the %3s (you used %4s, but you should have allocated a 5-char buffer for that) after the %7s that is already there. Note that the comparisons are for things like (sscanf() >= 5) in nearly all cases; the zone is already expected to be missing, so it won't hurt to also ignore a missing DST (not) tacked on after the zone. The only one where you need the explicit match is one where the zone name appears in the middle of the string. -- Bart Schaefer schaefer(a)cse.ogi.edu

1 0

australasia zoneinfo
by cvl!cvl!mimsy!uunet!munnari!physiol.su.oz.au!daved March 3, 1990

March 3, 1990

I have just modified our Australasia zoneinfo file to take account of changes in the NSW rule, and have incorporated changes distributed from Queensland and South Australia over the Australian news recently. I have also added code for Lord Howe Island (perhaps not in the most efficient manner possible). Lord Howe maintains GMT+10:30 when the New South Wales mainland is observing GMT+10:00. When the mainland moves to daylight saving time, it adopts the same time, namely GMT+11:00. So its "saving" is only 30 minutes. My complete file follows: # @(#)australasia 4.1+ (daved mods) # Incorporates updates for Australia from Robert Elz' australia 1.1 # and further updates from the Australian consulate. # Australian Data (for states with DST), standard rules # Includes shift in 1987 to follow Vic/NSW rules for ending DST, # and shift in 1986 to start DST earlier. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Oz 1971 1985 - Oct lastSun 2:00 1:00 - Rule Oz 1986 max - Oct Sun<=24 2:00 1:00 - Rule Oz 1972 only - Feb 27 3:00 0 - Rule Oz 1973 1986 - Mar Sun>=1 3:00 0 - Rule Oz 1987 max - Mar Sun<=21 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Tasmania 10:00 Oz EST Zone Australia/North 9:30 - CST # No DST here Zone Australia/West 8:00 - WST # No DST here Zone Australia/South 9:30 SA CST # The government seems to change things by regulation, not by changing the act. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SA 1971 1985 - Oct lastSun 2:00 1:00 - Rule SA 1972 1985 - Mar Sun>=1 3:00 0 - Rule SA 1986 only - Mar 16 3:00 0 - Rule SA 1986 only - Oct 19 2:00 1:00 - Rule SA 1987 only - Mar 15 3:00 0 - Rule SA 1987 max - Oct lastSun 2:00 1:00 - Rule SA 1988 only - Mar 20 3:00 0 - Rule SA 1989 max - Mar Sun<=21 3:00 0 - # Victoria jumped to a later ending date for DST in 1986 rather than 1987. Zone Australia/Victoria 10:00 Oz EST 1985 Oct lastSun 2:00 10:00 1:00 EST 1986 Mar Sun<=21 3:00 10:00 Oz EST # New South Wales and subjurisdictions have their own ideas of a fun time. # Based on law library research by John Mackin (john(a)basser.cs.su.oz) # who notes: # In Australia, time is not legislated federally, but rather by the # individual states. Thus, while such terms as ``Eastern Standard Time'' # [I mean, of course, Australian EST, not any other kind] are in common # use, _they have NO REAL MEANING_, as they are not defined in the # legislation. This is very important to understand. # I have researched New South Wales time only. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NSW 1971 1985 - Oct lastSun 2:00 1:00 - Rule NSW 1972 only - Feb lastSun 3:00 0 - Rule NSW 1973 1981 - Mar Sun>=1 3:00 0 - Rule NSW 1982 only - Apr 4 3:00 0 - Rule NSW 1983 1985 - Mar Sun>=1 3:00 0 - Rule NSW 1986 only - Mar 16 3:00 0 - Rule NSW 1986 only - Oct 19 2:00 1:00 - Rule NSW 1987 only - Mar 15 3:00 0 - Rule NSW 1987 max - Oct lastSun 2:00 1:00 - Rule NSW 1988 only - Mar Sun>=1 3:00 0 - Rule NSW 1989 only - Mar Sun<=21 3:00 0 - Rule NSW 1990 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/NSW 10:00 NSW EST Zone Australia/Broken-Hill 9:00 NSW ??? Zone Australia/Sturt 9:00 NSW ??? Zone Australia/Yancowinna 9:30 NSW ??? # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule LHI 1971 1985 - Oct lastSun 2:00 0:30 - Rule LHI 1972 only - Feb lastSun 3:00 0 - Rule LHI 1973 1981 - Mar Sun>=1 3:00 0 - Rule LHI 1982 only - Apr 4 3:00 0 - Rule LHI 1983 1985 - Mar Sun>=1 3:00 0 - Rule LHI 1986 only - Mar 16 3:00 0 - Rule LHI 1986 only - Oct 19 2:00 0:30 - Rule LHI 1987 only - Mar 15 3:00 0 - Rule LHI 1987 max - Oct lastSun 2:00 0:30 - Rule LHI 1988 only - Mar Sun>=1 3:00 0 - Rule LHI 1989 only - Mar Sun<=21 3:00 0 - Rule LHI 1990 max - Mar Sun>=1 3:00 0 - Zone Australia/LHI 10:30 LHI ??? # Queensland introduced DST for a `trial' period of 1 year # Based on the Daylight Saving Act 1989, No. 78 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule QLD 1989 only - Oct 29 2:00 1:00 - Rule QLD 1990 only - Mar 4 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Queensland 10:00 QLD EST # New Zealand, from Elz' asia 1.1 # Elz says "no guarantees" # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NZ 1974 max - Oct lastSun 2:00 1:00 D Rule NZ 1975 max - Mar Sun>=1 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone NZ 12:00 NZ NZ%sT # New Zealand # # A footnote here: # # . . . # Date: Thu, j19 Feb 87 12:02:17 EST # From: Bradley White <seismo!k.cs.cmu.edu!bww> # . . . # I am including a description of Australian time zones. . . # this stuff is definitely accurate. # . . . # a) Australian Eastern Time: (EST = GMT+10:00, EDT = GMT+11:00) # . . . # Summer of 86/87 - present (current legislation): # third Sun Oct 02:00 EST -> third LSun Mar 02:00 EST # # If this turns out to be true, substitute Sun<=21 (third Sunday in October) # for Sun<=24 (next-to-last Sunday in October) above. . .some time before # October 1988, the first time it makes a difference. #

1 0

Updated leap seconds file
by ado Oct. 15, 1989

Oct. 15, 1989

Word just in is that there'll be a leap second at the end of the year. --ado *** 7.1/leapseconds Sat Oct 14 20:44:25 1989 --- 7.2/leapseconds Sat Oct 14 20:44:26 1989 *************** *** 1,4 **** ! # @(#)leapseconds 7.1 # Allowance for leapseconds added to each timezone file. --- 1,4 ---- ! # @(#)leapseconds 7.2 # Allowance for leapseconds added to each timezone file. *************** *** 26,28 **** --- 26,29 ---- 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

1 0

POSIX conformance for file-based date(1)
by ado Aug. 22, 1989

Aug. 22, 1989

The 1989 version of the file-based "date" command is missing the 'c' in the argument to getopt that's needed to enable its POSIX-conformant handling of a command-line 'c' option. The needed change is attached. --ado *** 7.1/date.c Mon Aug 21 21:26:46 1989 --- 7.2/date.c Mon Aug 21 21:26:48 1989 *************** *** 2,4 **** #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.1"; /* --- 2,4 ---- #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.2"; /* *************** *** 103,105 **** format = value = NULL; ! while ((ch = getopt(argc, argv, "und:t:a:")) != EOF) { switch (ch) { --- 103,105 ---- format = value = NULL; ! while ((ch = getopt(argc, argv, "ucnd:t:a:")) != EOF) { switch (ch) {

1 0

New "europe" file reflecting Peter Ilieve's information
by ado July 18, 1989

July 18, 1989

# @(#)europe 7.2 # International country codes are used to identify countries' rules and # zones # # This data is by no means authoritative; if you think you know better, go # ahead and edit the file (and please send any changes to # ado(a)ncifcrf.gov for general use in the future). ############################################################################### # United Kingdom # From Peter Ilieve (peter(a)memex.co.uk) (July 4, 1989) # # From the UK Government paper "Summer Time: A Consultation Document" # (HMSO Cm722 June 1989), which is about the possibility of the UK moving # into the central European timezone and synchronising its summer time with # the rest of Europe (by moving the end date back a month to end Sep., # the start dates are already the same). # # Summer time was not observed before 1916. # It was introduced in the First World War in response to its introduction # by Germany in March 1916. # During the Second World War normal summer time was used in Winter and double # summer time was used in Summer. # Between 1968 and 1971 GMT+1 was used all year as an experiment. # This caused voluble objections in Scotland and the experiment was judged # a failure. # # Although it does not say what happens in Europe, it does say that most # of Europe did not use summer time until 1979, presumably dropping it # after the 1st and/or 2nd war. # # Note that this is not necessarily accurate for Eire. # # The paper gives a complete record of dates from 1916, and dates up to 1992. # The intention is to have the new system, if any, start in 1993. # The dates are (copied exactly from the table in the paper): # # Summer Time Double Summer Time # Year Start End Start End # 1916 21 May 1 October # 1917 8 April 17 September # 1918 24 March 30 September # 1919 30 March 29 September # 1920 28 March 25 October # (extended from # 27 Sep. because # of coal strike) # # 1921 3 April 3 October # 1922 26 March 8 October # 1923 22 April 16 September # 1924 30 April 21 September # 1925 to 3rd Sunday 1st Sunday # 1938 in April in October # # 1939 16 April 19 November # 1940 25 February continued # 1941 continued continued 4 May 10 August # 1942 continued continued 5 April 9 August # 1943 continued continued 4 April 15 August # 1944 continued continued 2 April 17 September # 1945 continued 7 October 2 April 15 July # # 1946 14 April 6 October # 1947 16 March 2 November 13 April 10 August # 1948 14 March 31 October # 1949 3 April 30 October # 1950 16 April 22 October # 1951 15 April 21 October # 1952 20 April 26 October # # 1953 19 April 4 October # 1954 11 April 3 October # 1955 17 April 2 October # 1956 15 April 7 October # 1957 14 April 6 October # 1958 20 April 5 October # 1959 19 April 4 October # 1960 10 April 2 October # # 1961 26 March 29 October # 1962 25 March 28 October # 1963 31 March 27 October # 1964 22 March 25 October # 1965 21 March 24 October # 1966 20 March 23 October # 1967 19 March 29 October # # 1968 18 February continued # 1969 continued continued # 1970 continued continued # 1971 continued 31 October # 1972 19 March 29 October # 1973 18 March 28 October # 1974 17 March 27 October # # 1975 16 March 26 October # 1976 21 March 24 October # 1977 20 March 23 October # 1978 19 March 29 October # 1979 18 March 28 October # 1980 16 March 26 October # 1981 29 March 25 October # # 1982 28 March 24 October # 1983 27 March 23 October # 1984 25 March 28 October # 1985 31 March 27 October # 1986 30 March 26 October # 1987 29 March 25 October # 1988 27 March 23 October # # 1989 26 March 29 October # 1990 25 March 28 October # 1991 31 March 27 October # 1992 29 March 25 October # # These dates agree with the ones from Whitaker's Almanac for 1960--87. . . # From Arthur David Olson (January 19, 1989): # # A source at the British Information Office in New York avers that it's # known as "British" Summer Time in all parts of the United Kingdom. # From an Anonymous U. K. Donor (January 4, 1989): # # It is NOT possible to predict when [British Summer Time] will change # in a future year. # # (The admiralty calculate when they think it should be (no more that a couple # of years in advance) and advise the government who then decide whether or # not they will take the admiralty's advice) # # ...the Gre[e]nwich...observatory...[was] very helpful. # # I was not able to track down the Admiralty formula (I tried hard but failed) # ... # Date: 4 Jan 89 08:57:25 GMT (Wed) # From: Jonathan Leffler <nih-csl!uunet!mcvax!sphinx.co.uk!john> # ... # [British Summer Time] is fixed annually by Act of Parliament. # If you can predict what Parliament will do, you should be in # politics making a fortune, not computing. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # 1916 to 1925--irregular Rule GB-Eire 1916 only - Mar 21 1:00s 1:00 BST Rule GB-Eire 1916 only - Oct 1 1:00s 0 GMT Rule GB-Eire 1917 only - Apr 8 1:00s 1:00 BST Rule GB-Eire 1917 only - Sep 17 1:00s 0 GMT Rule GB-Eire 1918 only - Mar 24 1:00s 1:00 BST Rule GB-Eire 1918 only - Sep 30 1:00s 0 GMT Rule GB-Eire 1919 only - Mar 30 1:00s 1:00 BST Rule GB-Eire 1919 only - Sep 29 1:00s 0 GMT Rule GB-Eire 1920 only - Mar 28 1:00s 1:00 BST Rule GB-Eire 1920 only - Oct 25 1:00s 0 GMT Rule GB-Eire 1921 only - Apr 3 1:00s 1:00 BST Rule GB-Eire 1921 only - Oct 3 1:00s 0 GMT Rule GB-Eire 1922 only - Mar 26 1:00s 1:00 BST Rule GB-Eire 1922 only - Oct 8 1:00s 0 GMT Rule GB-Eire 1923 only - Apr 22 1:00s 1:00 BST Rule GB-Eire 1923 only - Oct 16 1:00s 0 GMT Rule GB-Eire 1924 only - Apr 30 1:00s 1:00 BST Rule GB-Eire 1924 only - Sep 21 1:00s 0 GMT # 1925 to 1939 start--regular Rule GB-Eire 1925 1939 - Apr Sun>=15 1:00s 1:00 BST Rule GB-Eire 1925 1938 - Oct Sun>=1 1:00s 0 GMT # 1939 end to 1947--irregular, and with double summer time Rule GB-Eire 1939 only - Nov 19 1:00s 0 GMT Rule GB-Eire 1940 only - Feb 25 1:00s 1:00 BST Rule GB-Eire 1941 only - May 4 1:00s 2:00 DST Rule GB-Eire 1941 only - Aug 10 1:00s 1:00 BST Rule GB-Eire 1942 only - Apr 5 1:00s 2:00 DST Rule GB-Eire 1942 only - Aug 9 1:00s 1:00 BST Rule GB-Eire 1943 only - Apr 4 1:00s 2:00 DST Rule GB-Eire 1943 only - Aug 15 1:00s 1:00 BST Rule GB-Eire 1944 only - Apr 2 1:00s 2:00 DST Rule GB-Eire 1944 only - Sep 17 1:00s 1:00 BST # Double daylight starts on a Monday in 1945? Rule GB-Eire 1945 only - Apr 2 1:00s 2:00 DST Rule GB-Eire 1945 only - Jul 15 1:00s 1:00 BST Rule GB-Eire 1945 only - Oct 7 1:00s 0 GMT Rule GB-Eire 1946 only - Apr 14 1:00s 1:00 BST Rule GB-Eire 1946 only - Oct 6 1:00s 0 GMT Rule GB-Eire 1947 only - Mar 16 1:00s 1:00 BST Rule GB-Eire 1947 only - Apr 13 1:00s 2:00 DST Rule GB-Eire 1947 only - Aug 10 1:00s 1:00 BST Rule GB-Eire 1947 only - Nov 2 1:00s 0 GMT # So much for double saving time. 1948 and 1949, irregular. Rule GB-Eire 1948 only - Mar 14 1:00s 1:00 BST Rule GB-Eire 1948 only - Oct 31 1:00s 0 GMT Rule GB-Eire 1949 only - Apr 3 1:00s 1:00 BST Rule GB-Eire 1949 only - Oct 30 1:00s 0 GMT # 1950 through start of 1953, regular. Rule GB-Eire 1950 1953 - Apr Sun>=14 1:00s 1:00 BST Rule GB-Eire 1950 1952 - Oct Sun>=21 1:00s 0 GMT # 1954 to 1980, starting rules Rule GB-Eire 1954 only - Apr 11 1:00s 1:00 BST Rule GB-Eire 1955 1959 - Apr Sun>=14 1:00s 1:00 BST Rule GB-Eire 1960 only - Apr 10 1:00s 1:00 BST Rule GB-Eire 1961 1963 - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1964 1967 - Mar Sun>=19 1:00s 1:00 BST Rule GB-Eire 1968 only - Feb 18 1:00s 1:00 BST Rule GB-Eire 1972 1980 - Mar Sun>=16 1:00s 1:00 BST # 1953 to 1971, ending rules Rule GB-Eire 1953 1960 - Oct Sun>=1 1:00s 0 GMT Rule GB-Eire 1961 1967 - Oct Sun>=23 1:00s 0 GMT Rule GB-Eire 1971 only - Oct 31 1:00s 0 GMT # Current rules Rule GB-Eire 1981 max - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1972 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone GB-Eire 0:00 GB-Eire %s 1968 Oct 27 1:00s 1:00 - BST 1971 Oct 31 1:00s 0:00 GB-Eire %s ############################################################################### # Continental Europe # The use of 1986 as starting years below is conservative. Rule W-Eur 1986 max - Mar lastSun 1:00s 1:00 " DST" Rule W-Eur 1986 max - Sep lastSun 1:00s 0 - Rule M-Eur 1986 max - Mar lastSun 2:00s 1:00 " DST" Rule M-Eur 1986 max - Sep lastSun 2:00s 0 - Rule E-Eur 1986 max - Mar lastSun 3:00s 1:00 " DST" Rule E-Eur 1986 max - Sep lastSun 3:00s 0 - Rule Turkey 1986 max - Mar lastSun 1:00 1:00 " DST" Rule Turkey 1986 max - Sep lastSun 1:00 0 - Rule W-SU 1986 max - Mar lastSun 2:00s 1:00 " DST" Rule W-SU 1986 max - Sep lastSun 2:00s 0 - # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone WET 0:00 W-Eur WET%s Zone Iceland 0:00 - WET Zone MET 1:00 M-Eur MET%s Zone Poland 1:00 W-Eur MET%s Zone EET 2:00 E-Eur EET%s Zone Turkey 3:00 Turkey EET%s Zone W-SU 3:00 M-Eur ???? # Tom Hoffman says that MET is also known as Central European Time Link MET CET ############################################################################### # One source shows that Bulgaria, Cyprus, Finland, and Greece observe DST from # the last Sunday in March to the last Sunday in September in 1986. # The source shows Romania changing a day later than everybody else. # # According to Bernard Sieloff's source, Poland is in the MET time zone but # uses the WE DST rules. The Western USSR uses EET+1 and ME DST rules. # Bernard Sieloff's source claims Romania switches on the same day, but at # 00:00 standard time (i.e., 01:00 DST). It also claims that Turkey # switches on the same day, but switches on at 01:00 standard time # and off at 00:00 standard time (i.e., 01:00 DST) # ... # Date: Wed, 28 Jan 87 16:56:27 -0100 # From: seismo!mcvax!cgcha!wtho (Tom Hofmann) # Message-Id: <8701281556.AA22174(a)cgcha.uucp> # ... # # ...the European time rules are...standardized since 1981, when # most European coun[tr]ies started DST. Before that year, only # a few countries (UK, France, Italy) had DST, each according # to own national rules. In 1981, however, DST started on # 'Apr firstSun', and not on 'Mar lastSun' as in the following # years... # But also since 1981 there are some more national exceptions # than listed in 'europe': Switzerland, for example, joined DST # one year later, Denmark ended DST on 'Oct 1' instead of 'Sep # lastSun' in 1981---I don't know how they handle now. # # Finally, DST ist always from 'Apr 1' to 'Oct 1' in the # Soviet Union (as far as I know). # # Tom Hofmann, Scientific Computer Center, CIBA-GEIGY AG, # 4002 Basle, Switzerland # UUCP: ...!mcvax!cernvax!cgcha!wtho # ... # Date: Wed, 4 Feb 87 22:35:22 +0100 # From: seismo!mcvax!cwi.nl!dik (Dik T. Winter) # ... # # The information from Tom Hofmann is (as far as I know) not entirely correct. # After a request from chongo at amdahl I tried to retrieve all information # about DST in Europe. I was able to find all from about 1969. # # ...standardization on DST in Europe started in about 1977 with switches on # first Sunday in April and last Sunday in September... # In 1981 UK joined Europe insofar that # the starting day for both shifted to last Sunday in March. And from 1982 # the whole of Europe used DST, with switch dates April 1 and October 1 in # the Sov[i]et Union. In 1985 the SU reverted to standard Europe[a]n switch # dates... # # It should also be remembered that time-zones are not constants; e.g. # Portugal switched in 1976 from MET (or CET) to WET with DST... # Note also that though there were rules for switch dates not # all countries abided to these dates, and many individual deviations # occurred, though not since 1982 I believe. Another note: it is always # assumed that DST is 1 hour ahead of normal time, this need not be the # case; at least in the Netherlands there have been times when DST was 2 hours # in advance of normal time. # # ... # dik t. winter, cwi, amsterdam, nederland # INTERNET : dik(a)cwi.nl # BITNET/EARN: dik@mcvax # From Bob Devine (January 28, 1988): # ... # Greece: Last Sunday in April to last Sunday in September (iffy on dates). # Since 1978. Change at midnight. # ... # Monaco: has same DST as France. # ...

1 0

British summer time dates from the horse's mouth
by ado July 17, 1989

July 17, 1989

Here's a note I received last week, quoted with permission. A new "europe" file should follow shortly, reflecting at least the 1990, 1991, and 1992 information. --ado > From ncifcrf!@NSFnet-Relay.AC.UK:@cs.heriot-watt.ac.uk:peter@memex.co.uk Thu Jul 13 09:48:05 1989 > Return-Path: <ncifcrf!@NSFnet-Relay.AC.UK:@cs.heriot-watt.ac.uk:peter@memex.co.uk> > Received: from ncifcrf.UUCP by elsie (4.0/SMI-4.0) > id AA09957; Thu, 13 Jul 89 09:48:03 EDT > Received: from NSFnet-Relay.AC.UK by fcs280s.ncifcrf.gov (4.0/NCIFCRF-1.0) > id AA25601; Thu, 13 Jul 89 04:54:06 EDT > Received: from cs.heriot-watt.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP > id aa01688; 13 Jul 89 9:17 BST > Received: by doc.memex.co.uk (5.54/memex_12) > id AA20380; Tue, 4 Jul 89 10:30:35 BST > Date: Tue, 4 Jul 89 10:30:35 BST > From: Peter Ilieve <ncifcrf!NSFnet-Relay.AC.UK!peter%memex.co.uk> > Message-Id: <8907040930.AA20380(a)doc.memex.co.uk> > To: fcs280s!ado > Subject: British summer time dates from the horse's mouth > Status: RO > > >From the UK Government paper "Summer Time: A Consultation Document" > (HMSO Cm722 June 1989), which is about the possibility of the UK moving > into the central European timezone and synchronising its summer time with > the rest of Europe (by moving the end date back a month to end Sep., > the start dates are already the same). > > Summer time was not observed before 1916. > It was introduced in the First World War in response to its introduction > by Germany in March 1916. > During the Second World War normal summer time was used in Winter and double > summer time was used in Summer. > Between 1968 and 1971 GMT+1 was used all year as an experiment. > This caused voluble objections in Scotland and the experiment was judged > a failure. > > Although it does not say what happens in Europe, it does say that most > of Europe did not use summer time until 1979, presumably dropping it > after the 1st and/or 2nd war. > > Note that this is not necessarily accurate for Eire. > > The paper gives a complete record of dates from 1916, and dates up to 1992. > The intention is to have the new system, if any, start in 1993. > The dates are (copied exactly from the table in the paper): > > Summer Time Double Summer Time > Year Start End Start End > 1916 21 May 1 October > 1917 8 April 17 September > 1918 24 March 30 September > 1919 30 March 29 September > 1920 28 March 25 October > (extended from > 27 Sep. because > of coal strike) > > 1921 3 April 3 October > 1922 26 March 8 October > 1923 22 April 16 September > 1924 30 April 21 September > 1925 to 3rd Sunday 1st Sunday > 1938 in April in October > > 1939 16 April 19 November > 1940 25 February continued > 1941 continued continued 4 May 10 August > 1942 continued continued 5 April 9 August > 1943 continued continued 4 April 15 August > 1944 continued continued 2 April 17 September > 1945 continued 7 October 2 April 15 July > > 1946 14 April 6 October > 1947 16 March 2 November 13 April 10 August > 1948 14 March 31 October > 1949 3 April 30 October > 1950 16 April 22 October > 1951 15 April 21 October > 1952 20 April 26 October > > 1953 19 April 4 October > 1954 11 April 3 October > 1955 17 April 2 October > 1956 15 April 7 October > 1957 14 April 6 October > 1958 20 April 5 October > 1959 19 April 4 October > 1960 10 April 2 October > > 1961 26 March 29 October > 1962 25 March 28 October > 1963 31 March 27 October > 1964 22 March 25 October > 1965 21 March 24 October > 1966 20 March 23 October > 1967 19 March 29 October > > 1968 18 February continued > 1969 continued continued > 1970 continued continued > 1971 continued 31 October > 1972 19 March 29 October > 1973 18 March 28 October > 1974 17 March 27 October > > 1975 16 March 26 October > 1976 21 March 24 October > 1977 20 March 23 October > 1978 19 March 29 October > 1979 18 March 28 October > 1980 16 March 26 October > 1981 29 March 25 October > > 1982 28 March 24 October > 1983 27 March 23 October > 1984 25 March 28 October > 1985 31 March 27 October > 1986 30 March 26 October > 1987 29 March 25 October > 1988 27 March 23 October > > 1989 26 March 29 October > 1990 25 March 28 October > 1991 31 March 27 October > 1992 29 March 25 October > > These dates agree with the ones from Whitaker's Almanac for 1960--87 > you quoted in your latest posting of the tzone stuff. > > If we do go into the CET zone then you will have one less thing to worry > about in future. > > Peter Ilieve peter(a)memex.co.uk > >

1 0

Re: machine independence
by Arthur David Olson April 20, 1989

April 20, 1989

> So do you remember how the rest of us (Elz, me, Bob Device, Bradley White, > etc.) got involved? I don't, but the computer does. (One advantage of working on image processing is big disks and lots of tapes.) There was a fair amount of mod.std.unix posting in early '86, kicked off by Mark Horton's original "How best to handle time conversion?" posting. Bob Devine responded since he'd been responsible for time stuff with an earlier employer; he was person who knew that astrologers had the best information about DST in the past. Robert Elz was motivated by the fact that the Australian government fiddled the DST rules down there for a visit by the Queen in March of '86. He boldly installed the early code just before the visit. Robert's changes to "date" to work with the new functions showed up in mod.sources in June of '86. Robert knew of your work before I did: > From munnari!kre Tue Aug 26 13:10:08 1986 remote from seismo > . . . > To: elsie!ado > . . . > Did Guy Harris (sun!guy) ever send you his mods to this stuff? > He has made the compiled timezone files be in "standard" format > so they can reside on one host on a net, and have others access > them (by NFS or whatever), regardless of whether there's a mixture > of Sun's vaxen, etc, with different byte orders & such. Clearly the mods had been sent by the time that the "timezone mailing list" was announced in late '86: > From ado Mon Nov 24 19:58:54 1986 > . . . > To: tz > Subject: seismo!elsie!tz ; new versions of time zone stuff > > Now that we've moved from 4.1BSD to 4.3BSD here at elsie, > I've set things up so that mail sent to > seismo!elsie!tz > will go to folks who've expressed an interest in time zone matters. . . > Currently on the list: > ado(a)elsie.UUCP > chris(a)umcp-cs.UUCP > mark(a)cbosgd.ATT.COM > kre(a)munnari.OZ > dlm(a)cuuxb.ATT.COM > devine(a)vianet.UUCP > bob(a)anvil.UUCP > rgt(a)hpfcdg.UUCP > guy(a)sun.UUCP > . . . > And now the real news: new versions of the time zone compiler, the > ctime et al. library, and the time zone data are available. Guy Harris > provided the bulk of the ideas and work that went into the new versions, > but should be held innocent of any blame for errors since I've tinkered > with Guy's work (in part to try for more compatibility with System V and > the work of rgt(a)hpfcdg.UUCP, who's the time zone person at Hewlett-Packard). > . . . (How it is that I forgot after then how to spell compatibility is beyond me.) The mailing list saw a flurry of activity in December of '86, with an upcoming P1003 meeting due to try to figure out how to standardize time conversion; H-P was preparing an alternative proposal to "P.55," which was based on the table-driven stuff. As part of the flurry, John S. Quarterman (who carried the banner before P1003) got involved at kre's behest: > From seismo!munnari!kre Sun Dec 7 06:57:42 1986 > . . . > To: elsie!tz > Cc: jsq(a)sally.utexas.edu > Subject: timezone proposals for P1003 > . . . > I think things are getting way too complicated. > > All P1003 needs (and all it should have) is a spec of > the interface that programs should have to time conversions. > . . . > Robert Elz seismo!munnari!kre > > ps: I have added a cc to John Quarterman, who I guess is > as close as anyone to being my representative on P1003, > given that I'm a usenix member... John, this is in response > to some discussions over the HP proposals and other replated > issues. elsie!ado can fill you in on what's been going on I think. > There's a mailing list at elsie for tz discussions. Bradley White first appears (at least in my back mail files) in early '87: (presumably after the P1003 meeting?); he was referred by. . . > From seismo!sun!guy Thu Feb 19 06:56:54 1987 > ... > To: elsie!ado > Subject: Could you send him the latest version when it's ready? > Cc: bww(a)k.cs.cmu.edu > Status: RO > > > From: Bradley White <bww(a)k.cs.cmu.edu> > > Subject: Re: diffs for ctime.c for new DST rules, v7 systems > > To: guy(a)Sun.COM > > > Guy, > > > If you could send me (or point me at) a copy of Arthur Olson's "ctime" > > I will have it installed in CMU Mach/Unix. Hopefully this will aid in > > its dissemination. > ... --ado

1 0

Re: machine independence
by Arthur David Olson April 20, 1989

April 20, 1989

> Speaking of "the original ... work", how did this all get started, > anyway? The ultimate impetus was the legislation that changed the start of U. S. Daylight Saving Time from the last Sunday in April to the first Sunday in April. The proximate impetus was a mod.std.unix discussion on the subject. I've attached some of the early electronic mail. By 1/11/86 the format looked much as it does today. The "hard part" not dealt with in the 1/13/86 "distribution" was the text-format-to-binary-format converter (today's zic). --ado > From ado Mon Jan 6 10:28:48 1986 > To: cbosgd!mark > Subject: Daylight Savings Time > Cc: seismo!philabs!linus!encore!necis!geo > Status: O > > Well, I'll admit that my first reaction to the idea of something on the order > of "/etc/dstcap" was a smiley face. But over the weekend I thought about the > matter some more. The result of the thinking was a sheet of paper with this > on it: > > > eastern:\ > > :st=EST:\ > > :dt=EDT:\ > > :os=-21000:\ > ... > Now regardless of the way the above information is encoded, the questions are: > Is there enough information present above to deal with the various > Daylight Saving Time schemes that currently exist? Would the information be > enough to deal with anything that US (or foreign) legislators are likely > to dream up? Or does one *really* need to have something on the order of > "/etc/dstinfo" (with a stack and arithmetic and such)? > > --ado > >From cbosgd!cbpavo.cbosgd.ATT.UUCP!mark Fri Jan 10 16:19:08 1986 remote from seismo > Received: from cbosgd.UUCP by seismo.CSS.GOV with UUCP; Fri, 10 Jan 86 16:05:29 EST > Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) > by cbosgd.ATT.UUCP (4.12/UUCP-Project/11.09.85) > id AA17523; Fri, 10 Jan 86 15:04:29 est > Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) > id AA03218; Fri, 10 Jan 86 15:04:20 est > Date: Fri, 10 Jan 86 15:04:20 est > From: seismo!cbpavo.cbosgd.ATT.UUCP!mark (Mark Horton) > Message-Id: <8601102004.AA03218(a)cbpavo.cbosgd.ATT.UUCP> > To: elsie!ado, harvard!encore!encore!necis!geo > Subject: Re: Daylight Savings Time > > While I like your semantics, the format is horrible. I'd much > prefer to see each year (or year range) in one place rather > than have it scattered over 14 different days of the week. > The format has to be something the average non-guru can understand. > Termcap is a bit much for such people. Something easy like > > Year Key Parm Time GMT offset > 1970 3-sun 4 0200 -0400 > 1970 3-sun 10 0200 -0500 > 1971 3-sun 4 0200 -0400 > 1971 3-sun 10 0200 -0500 > 1972 3-sun 4 0200 -0400 > 1972 3-sun 10 0200 -0500 > 1973 3-sun 4 0200 -0400 > 1973 3-sun 10 0200 -0500 > 1974 julian 120 0200 -0400 > 1974 julian 306 0200 -0500 > 1975 julian 0 0200 -0400 > 1975 julian 366 0200 -0500 > 1976 3-sun 4 0200 -0400 > 1976 3-sun 10 0200 -0500 > > This could probably be translated into a handy binary format for ctime > to use quickly. The parm is either the month number (for things like > "3rd Sunday") or the Julian date on which to make the change. The > above numbers are probably all wrong but you get the idea. You could > have any number of changes in a year, although 2 would be common. > > Mark > From ado Sat Jan 11 12:42:16 1986 > To: cbosgd!mark > Subject: DST > Status: O > > An alternate approach to allow for multiple time zones. Make the rules look > like: > > Rule Year(s) Month Day Time ST offset String > MostUS -1973 Apr last-Sun 2:00 1:00 D > MostUS -1973 Oct last-Sun 2:00 0 S > MostUS 1974 Jan last-Sun 2:00 1:00 D > MostUS 1974 Nov last-Sun 2:00 0 S > MostUS 1975 Feb last-Sun 2:00 1:00 D > MostUS 1975 Oct last-Sun 2:00 0 S > MostUS 1976- Apr last-Sun 2:00 1:00 D > MostUS 1976- Oct last-Sun 2:00 0 S > Patron 1969- Apr last-Sun 2:00 1:00 D > Patron 1969- Jul last-Sun 2:00 2:00 DD > Patron 1969- Aug last-Sun 2:00 1:00 D > Patron 1969- Oct last-Sun 2:00 0 S > > and the Time Zone information look like > > Name GMT offset Rule Abbreviation > Eastern -5:00 MostUS E%sT > Central -6:00 MostUS C%sT > Pacific -8:00 MostUS P%sT > Alaskan ? MostUS A%sT > Hawaiian ? MostUS H%sT > Patronian ? Patron P%sT > > --ado > From ado Mon Jan 13 21:04:01 1986 > To: cbosgd!mark > Subject: The easy part of ctime() > Status: O > > The next letter from me should be a shell archive containing five files: > Makefile > timezone.h > ctime.c > try.c > fake.c > The important files are "timezone.h" which gives the format of "binary time > zone information files," and "ctime.c" which makes use of the files. . . ==============================================================

1 0

Re: leap seconds
by ado June 9, 1988

June 9, 1988

> After some phone calls to NBS and Naval Observatory, I found out > that there have been 14 leap seconds inserted. > > 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 > ... > 14) 1987 Dec 31 23:59:60 # Naval Observatory Which, providentially, agrees with the data in the comp.sources.unix posting. Hats off to bww and guy! --ado

1 0

Re: leap seconds
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 9, 1988

June 9, 1988

> The phase 'my clock is 14 seconds slow' has been used recently and is > one off from the 15 leap seconds listed above or the 17 leap seconds > which would have been added had Bob's statement been correct. After some phone calls to NBS and Naval Observatory, I found out that there have been 14 leap seconds inserted. 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 2) 1972 Dec 31 23:59:60 # NBS Special Publication #432 3) 1973 Dec 31 23:59:60 # NBS Special Publication #432 4) 1974 Dec 31 23:59:60 # NBS Special Publication #432 5) 1975 Dec 31 23:59:60 # NBS Special Publication #432 6) 1976 Dec 31 23:59:60 # NBS Special Publication #432 7) 1977 Dec 31 23:59:60 # NBS Special Publication #432 8) 1978 Dec 31 23:59:60 # NBS Special Publication #432 9) 1979 Dec 31 23:59:60 # Naval Observatory 10) 1981 Jun 30 23:59:60 # Naval Observatory 11) 1982 Jun 30 23:59:60 # Naval Observatory 12) 1983 Jun 30 23:59:60 # Naval Observatory 13) 1985 Jun 30 23:59:60 # Naval Observatory 14) 1987 Dec 31 23:59:60 # Naval Observatory The earth has been slowing down so there won't be a yearly insertion as there was in the 70s. Next leap second is anticipated to be in added in 1 1/2 or 2 years. Bob [ David Hoerl, could you send me mail directly? I can't reply to you using the address I got -- ...!decwrl.dec!cookie.dec.com!devine ]

1 0

Leap seconds
by Ronald G. Tolley June 6, 1988

June 6, 1988

>> 1973 June 30 23:59:60 >> 1973 June 30 23:59:61 > > Positive leap seconds were inserted in all NBS broadcasts > at the end of June 30, 1972 and December 31, 1972 thru 1978. > > [ All years since 1978 have had leap seconds. Bob] A AP article out of Washington written in about May 1985 states that "that [adding leap seconds] was done twice in 1972 and once every year since except 1980 and 1984." The same article stated that the 1985 leap second would be the last second in June. >From the data which has gone around recently including the comment above, I have constructed the following list of leap seconds: 1) 1972 Jun 30 23:59:60 # NBS Special Publication #432 2) 1972 Dec 31 23:59:60 # NBS Special Publication #432 3) 1973 Dec 31 23:59:60 # NBS Special Publication #432 4) 1974 Dec 31 23:59:60 # NBS Special Publication #432 5) 1975 Dec 31 23:59:60 # NBS Special Publication #432 6) 1976 Dec 31 23:59:60 # NBS Special Publication #432 7) 1977 Dec 31 23:59:60 # NBS Special Publication #432 8) 1978 Dec 31 23:59:60 # NBS Special Publication #432 9) 1979 Dec 31 23:59:60 # June or December? # AP Article no leap second in 1980 10) 1981 Dec 31 23:59:60 # June or December? 11) 1982 Dec 31 23:59:60 # June or December? 12) 1983 Dec 31 23:59:60 # June or December? # AP Article no leap second in 1984 13) 1985 Jun 30 23:59:60 # AP Article 14) 1986 Dec 31 23:59:60 # June or December? 15) 1987 Dec 31 23:59:60 # June or December? Is there a more complete or more correct list available? (All this fuss over a handful of seconds!) The phase 'my clock is 14 seconds slow' has been used recently and is one off from the 15 leap seconds listed above or the 17 leap seconds which would have been added had Bob's statement been correct. Ron Tolley

1 0

leap seconds; [0-60] is ok
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 2, 1988

June 2, 1988

> When the first leap seconds were added, which I believe were in 1973, > there were two inserted at the same time. Thus a single legal value has > had the seconds denoted as "61". From memory, these two leap seconds > were: > > 1973 June 30 23:59:60 > 1973 June 30 23:59:61 No, only one second is ever added at a time. However, Ron is right about the first year (1972) containing two leap seconds. Below is the relevant section describing how leap seconds are inserted/deleted. Bob Devine [ On a sidenote to time, the Herstmonceux Castle where the Greenwich Observatory is located is for sale. You can buy it for only ~$15M.] From the NBS Special Publication #432 (issued in 1979): When leap second adjustments are necessary to keep the broadcast time signals (UTC) within +/- 0.9 second of the earth-related UT1 time scale, the addition or deletion of exactly 1 second occurs at the end of the UTC month. By international agreement, first preference is given to December 31 or June 30, second preference to March 31 or September 30, and third preference to any other month. When a positive leap second is required -- that is, when UT1 is slow relative to UTC -- an additional second is inserted beginning 23h 59m 60s of the last day of the month and ending at 0h 0m 0s of the first day of the following month. In this case the last minute of the month in which there is a leap second contains 61 seconds. Assuming that unexpected large changes do not occur in the earth's rotation rate in the future, it is likely that positive leap seconds will continue to be needed about once per year. If, however, the earth should speed up significantly at some future time, so that UT1 runs at a _faster_ rate than UTC, then provision is also made for negative leap seconds in the UTC time scale. In this case, exactly one second would be deleted at the end of some UTC month, and the last minute would contain only 59 seconds. Positive leap seconds were inserted in all NBS broadcasts at the end of June 30, 1972 and December 31, 1972 thru 1978. [ All years since 1978 have had leap seconds. Bob]

1 0

Re: Time conversion and second public... [forwarded from rgt@hpfcrg]
by ado June 2, 1988

June 2, 1988

> * The range of seconds has been changed from "[0-59]" to "[0-60]" > throughout, to allow for leap seconds. Whether this is a good > thing or not depends on what you think POSIX wants. When the first leap seconds were added, which I believe were in 1973, there were two inserted at the same time. Thus a single legal value has had the seconds denoted as "61". From memory, these two leap seconds were: 1973 June 30 23:59:60 1973 June 30 23:59:61 All other leap seconds, as I recall, have been added singly so other than the single second noted above "[0-60]" would be sufficient. However if we are to do a complete job, let's handle this "61" too. Ron Tolley

1 0

Time conversion and second public review of draft proposed ANSI C
by ado June 1, 1988

June 1, 1988

I've yet to receive the draft proposed standard that's the subject of the third public review period; I have, though, received "X3J11 Response ot Issues Raised by Miscellaneous Public Comments (Not an official X3J11 document)." Here's what the "Response" has to say on time conversion matters: * The range of seconds has been changed from "[0-59]" to "[0-60]" throughout, to allow for leap seconds. Whether this is a good thing or not depends on what you think POSIX wants. * The Committee declined to change the phrase "time zone name" to "time zone name abbreviation". Some vendors will be surprised when they learn that "strftime" is supposed to fill structures with pointers to strings such as "mountain standard time" (which is a time zone name) rather than to strings such as "MST" (which is a time zone name abbreviation). Reading the Committee's response, I'm inclined to believe that I failed to clearly draw the distinction, and that a clearer explanation, along with a modified suggestion that the phrase be changed to "time zone name or abbreviation," might be more positively received. * The Committee declined to move the contents of footnote 109 into the Standard proper. In my letter to the Committee, I said: Footnote 109 reads Thus, a positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time. The described behavior of mktime when tm_isdst is negative cannot be deduced from the Standard proper; given Section 4.12.1's words that "The value of tm_isdst is. . .negative if the information is not available," an implementer of mktime could reasonably say "No information about DST is available, so we won't try to account for it." Proposed Change Move the text of footnote 109 into the Standard proper, changing "Thus, a positive. . ." to "A positive. . ." The "Response" indicates that the Committee believes the behavior described in footnote 109 represents the only reasonable interpretation of the standard. Looks as if the vendors will be able to take the easy way out (described above), and as if user's won't be able to rely on the "tm_isdst == -1" mechanism to get DST accounted for. -- "Only external identifiers and macro names described in the Standard as reserved shall be reserved" must go in. This is non-negotiable. ado(a)ncifcrf.gov ADO is a trademark of Ampex.

1 0

time representation
by ncifcrf!decwrl.dec.com!devine%cookie.DEC June 1, 1988

June 1, 1988

Bradley White says: > Just as an aside, UNIX time_t values are not an appropriate representation > of time in a distributed system. An ASCII rendition of UT is much better. To continue the aside: The appropriate ISO standards for representing date and time are: ISO 4031, ISO 3307, and ISO 2014. Send me mail if you want some functions that convert time_t to/from a subset of those ISO standards. Bob Devine

1 0

Re: tz package
by cvl!uts.amdahl.com!cvl!chongo May 31, 1988

May 31, 1988

>> I suggest that you put a BIG warning around the use of 'leapseconds' >> in time calculations. For a number of reasons, POSIX (IEEE standard >> Unix, soon to be ANSI and ISO standard unix) prohibits the standard >> conversion to/from "Seconds since the Epoch" functions from taking >> leapseconds into account. > >I think we came to the conclusion before doing the leapsecond stuff that >the wording in POSIX *requires* that standard conversion routines take >leapseconds into account. Just to be sure we have communicated... POSIX really does state that "seconds since the Epoch" explicitly excludes leap seconds in the calculation. Since all current POSIX time conversion functions and time_t timestamps derive their value from "seconds since the Epoch", no POSIX function can make use of leapseconds. This is not to say that a later draft could not add NEW functions that do take leap seconds into account. But since P1003.1 is NOW in FINAL BALLOT, it will be a long time before such a standard function would show up. The impact of adding leapseconds as you have done can be more than a simply 'my clock is 14 seconds slow'. Networks of systems or multi-os systems or multi-cpu systems could have a different time_t value for the current time. These systems could convert the same time_t value into a different string. Make can get messed up, transaction time stamps can be wrong, etc... That is why I suggested that you point a big warning about not using leapseconds. No system using them can ever be POSIX (or SVID since it will conform to POSIX) and no system as shipped by a major (or minor?) computer builder uses them. Is patch level 1 your current patch? chongo <> /\oo/\

2 2

Re: tz package
by ado May 30, 1988

May 30, 1988

> I started looking over your tz package. Thin[g]s look nice. Have you had > any patches since the posting? My Patchlevel.h file shows I am at > PATCHLEVEL #1. No "released to a source moderator" patches yet, and nothing that's very big. I've attached some "unofficial" diffs to the end of this letter: Makefile the suggestion to remove "timezone.o" from "libc.a" is deleted tzfile.h a redundant definition of TM_SUNDAY is deleted getopt.c is now the latest version from Berkeley (with an elsie header on the front to keep sccs happy) localtime.c has an added workaround for a bug in 3B1s. The 3B1 workaround is the change I'm least sure of; after I made it I sent it off to the person who originally reported the problem and asked for a blessing; I've yet to receive a response. In particular I'm not sure that conditioning on "m68k" is right; this may just be a 3B1 problem. A bit back Guy Harris sent along changes to allow localtime to handle POSIX-style TZ environment variables; as soon as I confirm that it's okay to do so, I can send these along. > I suggest that you put a BIG warning around the use of 'leapseconds' > in time calculations. For a number of reasons, POSIX (IEEE standard > Unix, soon to be ANSI and ISO standard unix) prohibits the standard > conversion to/from "Seconds since the Epoch" functions from taking > leapseconds into account. This means that if anyone does use the > timezone deltas, their system will be out of conformance. If leapseconds > are desired, then such systems need to use different time conversion > functions to do this. If you could work up a "chapter and verse" explanation, I'd be glad to add it to the distribution. Presumably the thing to do would be to have LEAPSECONDS default to /dev/null in the Makefile, with a note in the Makefile on how to get leapseconds accounted for and an explanation of why you might not want to. --ado *** 4.1/Makefile Mon May 30 12:26:20 1988 --- 4.2/Makefile Mon May 30 12:26:33 1988 *************** *** 1,4 **** ! # @(#)Makefile 4.1 # If you want something other than Eastern United States time used on your # system, change the line below (after finding the zone you want in the --- 1,4 ---- ! # @(#)Makefile 4.2 # If you want something other than Eastern United States time used on your # system, change the line below (after finding the zone you want in the *************** *** 14,20 **** # You may want to change this define if you're just testing the software. # Alternatively, you can put these functions in /lib/libc.a, removing ! # the old "ctime.o" (and "timezone.o" on a BSD system). This is the # ideal solution if you are able. Build libz.a, extract the files, and # then add them to libc.a. --- 14,20 ---- # You may want to change this define if you're just testing the software. # Alternatively, you can put these functions in /lib/libc.a, removing ! # the old "ctime.o". This is the # ideal solution if you are able. Build libz.a, extract the files, and # then add them to libc.a. *** 4.1/getopt.c Mon May 30 12:27:21 1988 --- 4.2/getopt.c Mon May 30 12:27:22 1988 *************** *** 1,16 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)getopt.c 4.1"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ ! #include "string.h" ! #ifndef strchr ! #define index strchr ! #endif /* !defined strchr */ #include <stdio.h> --- 1,28 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)getopt.c 4.2"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ ! /* ! * Copyright (c) 1987 Regents of the University of California. ! * All rights reserved. ! * ! * Redistribution and use in source and binary forms are permitted ! * provided that this notice is preserved and that due credit is given ! * to the University of California at Berkeley. The name of the University ! * may not be used to endorse or promote products derived from this ! * software without specific written prior permission. This software ! * is provided ``as is'' without express or implied warranty. ! */ ! #ifdef LIBC_SCCS ! #ifndef lint ! static char sccsid[] = "@(#)getopt.c 4.5 (Berkeley) 11/24/87"; ! #endif /* !defined lint */ ! #endif /* defined LIBC_SCCS */ #include <stdio.h> *************** *** 17,23 **** /* * get option letter from argument vector */ ! int opterr = 1, /* useless, never set or used */ optind = 1, /* index into parent argv vector */ optopt; /* character checked for validity */ char *optarg; /* argument associated with option */ --- 29,35 ---- /* * get option letter from argument vector */ ! int opterr = 1, /* if error message should be printed */ optind = 1, /* index into parent argv vector */ optopt; /* character checked for validity */ char *optarg; /* argument associated with option */ *************** *** 24,65 **** #define BADCH (int)'?' #define EMSG "" ! #define tell(s) fputs(*nargv,stderr);fputs(s,stderr); \ ! fputc(optopt,stderr);fputc('\n',stderr);return(BADCH); ! getopt(nargc,nargv,ostr) ! int nargc; ! char **nargv, ! *ostr; { ! static char *place = EMSG; /* option letter processing */ ! register char *oli; /* option letter list index */ char *index(); ! if(!*place) { /* update scanning pointer */ ! if(optind >= nargc || *(place = nargv[optind]) != '-' || !*++place) return(EOF); ! if (*place == '-') { /* found "--" */ ++optind; return(EOF); } ! } /* option letter okay? */ ! if ((optopt = (int)*place++) == (int)':' || !(oli = index(ostr,optopt))) { ! if(!*place) ++optind; tell(": illegal option -- "); } ! if (*++oli != ':') { /* don't need argument */ optarg = NULL; ! if (!*place) ++optind; } ! else { /* need an argument */ ! if (*place) optarg = place; /* no white space */ else if (nargc <= ++optind) { /* no arg */ place = EMSG; tell(": option requires an argument -- "); } ! else optarg = nargv[optind]; /* white space */ place = EMSG; ++optind; } ! return(optopt); /* dump back option letter */ } --- 36,90 ---- #define BADCH (int)'?' #define EMSG "" ! #define tell(s) { \ ! if (opterr) { \ ! fputs(*nargv, stderr); \ ! fputs(s, stderr); \ ! fputc(optopt, stderr); \ ! fputc((int)'\n', stderr); \ ! } \ ! return(BADCH); \ ! } ! getopt(nargc, nargv, ostr) ! int nargc; ! char **nargv, *ostr; { ! static char *place = EMSG; /* option letter processing */ ! register char *oli; /* option letter list index */ char *index(); ! if (!*place) { /* update scanning pointer */ ! if (optind >= nargc || *(place = nargv[optind]) != '-' || ! !*++place) ! return(EOF); ! if (*place == '-') { /* found "--" */ ++optind; return(EOF); } ! } /* option letter okay? */ ! if ((optopt = (int)*place++) == (int)':' || ! !(oli = index(ostr, optopt))) { ! if (!*place) ! ++optind; tell(": illegal option -- "); } ! if (*++oli != ':') { /* don't need argument */ optarg = NULL; ! if (!*place) ! ++optind; } ! else { /* need an argument */ ! if (*place) /* no white space */ ! optarg = place; else if (nargc <= ++optind) { /* no arg */ place = EMSG; tell(": option requires an argument -- "); } ! else /* white space */ ! optarg = nargv[optind]; place = EMSG; ++optind; } ! return(optopt); /* dump back option letter */ } *** 4.1/tzfile.h Mon May 30 12:25:44 1988 --- 4.2/tzfile.h Mon May 30 12:25:49 1988 *************** *** 2,8 **** #ifndef NOID #ifndef TZFILE_H #define TZFILE_H ! static char tzfilehid[] = "@(#)tzfile.h 4.1"; #endif /* !defined TZFILE_H */ #endif /* !defined NOID */ #endif /* !defined lint */ --- 2,8 ---- #ifndef NOID #ifndef TZFILE_H #define TZFILE_H ! static char tzfilehid[] = "@(#)tzfile.h 4.2"; #endif /* !defined TZFILE_H */ #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 107,113 **** #define TM_OCTOBER 9 #define TM_NOVEMBER 10 #define TM_DECEMBER 11 - #define TM_SUNDAY 0 #define TM_YEAR_BASE 1900 --- 107,112 ---- *** 4.1/localtime.c Mon May 30 12:49:30 1988 --- 4.6/localtime.c Mon May 30 12:49:47 1988 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 4.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 4.6"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 389,394 **** --- 389,403 ---- } days = *clock / SECSPERDAY; rem = *clock % SECSPERDAY; + #ifdef mc68k + if (*clock == 0x80000000) { + /* + ** A 3B1 muffs the division on the most negative number. + */ + days = -24855; + rem = -11648; + } + #endif /* mc68k */ rem += (offset - corr); while (rem < 0) { rem += SECSPERDAY;

1 0

tz package
by mcf!umix!ames!uts.amdahl.com!chongo May 30, 1988

May 30, 1988

I started looking over your tz package. Thinks look nice. Have you had any patches since the posting? My Patchlevel.h file shows I am at PATCHLEVEL #1. I suggest that you put a BIG warning around the use of 'leapseconds' in time calculations. For a number of reasons, POSIX (IEEE standard Unix, soon to be ANSI and ISO standard unix) prohibits the standard conversion to/from "Seconds since the Epoch" functions from taking leapseconds into account. This means that if anyone does use the timezone deltas, their system will be out of conformance. If leapseconds are desired, then such systems need to use different time conversion functions to do this. chongo <> /\oo/\

2 1

More converts?
by ado May 2, 1988

May 2, 1988

> Path: elsie!cvl!umd5!purdue!decwrl!labrea!rutgers!bellcore!tness7!ninja!sys1!sneaky!trsvax!uhclem > From: uhclem(a)trsvax.UUCP > Newsgroups: comp.sys.tandy > Subject: Re: Time on Tandy 3.2 > Message-ID: <193300057@trsvax> > Date: 25 Apr 88 15:43:00 GMT > References: <1618(a)scicom.alphacdc.com> > Lines: 66 > Nf-ID: #R:scicom.alphacdc.com:1618:trsvax:193300057:000:3009 > Nf-From: trsvax.UUCP!uhclem Apr 25 10:43:00 1988 ... > In XENIX 3.2, the routines that manage date conversions now examine a > file for the rules on how to handle DST. So if the U.S. government > changes the fall date (which is expected), or makes any other change, > a change to the rule-file will fix handling for all programs. This also > works nice if you happen to live in a country that is 15 minutes + solar time > or some other unusual local time convention. ... > Frank Durda IV > @ <trsvax!uhclem> > ...decvax!microsoft!trsvax!uhclem > ...convex!infoswx!hal6000!trsvax!uhclem I'm trying to find out if "the file" mentioned above is really the comp.sources.unix files. -- ado(a)ncifcrf.gov ADO is a trademark of Ampex.

1 0

Re: Interested in time.
by cvl!mimsy!uunet!Sun.COM!guy April 26, 1988

April 26, 1988

I recently looked at your excellent time package. However, it appeared to me that if someone in a foreign country got a copy of a machine with this code, that they would have a hard problem figuring out what TZ to use, as they are not enumerated in ctime.3 (at least in my copy), nor did there appear to be any tools to build such a file from the /etc/zoneinfo directory. My question is thus: have you developed a program that walks the directories, and builds a table of the available entries? The way we intend to solve this for SunOS 4.0 is to give a listing of the various TZ values, and the areas to which particular values apply, in the "installing SunOS" documentation.

1 0

Interested in time.
by DF Hoerl April 24, 1988

April 24, 1988

I recently looked at your excellent time package. However, it appeared to me that if someone in a foreign country got a copy of a machine with this code, that they would have a hard problem figuring out what TZ to use, as they are not enumerated in ctime.3 (at least in my copy), nor did there appear to be any tools to build such a file from the /etc/zoneinfo directory. My question is thus: have you developed a program that walks the directories, and builds a table of the available entries? David Hoerl, AT&T Bell Labs PS: would you add me to the list of people interested in time? Thanks.

1 0

Time zone stuff
by suns!chase%orc.olivetti.com April 20, 1988

April 20, 1988

Is the time zone package which you provide in the public or "free" domain? If so, I wish to make use of it in the library for another language (Modula-3, but it is glued to an ANSI library). Thanks much, David Chase Olivetti Research Center, Menlo Park

1 0

Problem with new PD localtime
by cvl!mimsy!uunet!datapg.MN.ORG!sewilco April 8, 1988

April 8, 1988

Have any problems been reported with 'localtime' on a 3B1 (System V). Something seems to be wrong with my copy of 'zic'. All of the USA entries with daylight savings time are zeroed. For example, 'od -c CST6CDT' is: 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000054 Also, "zdump" reports all those times with a "GMT" label. Any suggestions? I had the same problem with the previous version and waited for the new one. Further details: I got errors of bad leapsecond values, so changed localtime to /dev/null. Changes in Makefile: LOCALTIME= US/Central TZDIR= /usr/local/zoneinfo LEAPSECONDS= /dev/null CFLAGS= -DSTD_INSPIRED -DUSG_COMPAT -DUSG # test -f /usr/bin/ranlib && ranlib $@ Changes to pacificnew: # Following four lines due to no PPET yet #Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE #Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S #Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S Rule Twilite 1987 max - Oct lastSun 2:00 0 S Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX consulting +1 612-825-2607 uunet!datapg!sewilco

1 0

Problems with new PD localtime
by suns!sewilco%datapg.mn.org April 8, 1988

April 8, 1988

Have any problems been reported with 'localtime' on a 3B1 (System V). Something seems to be wrong with my copy of 'zic'. All of the USA entries with daylight savings time are zeroed. For example, 'od -c CST6CDT' is: 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000054 Also, "zdump" reports all those times with a "GMT" label. Any suggestions? I had the same problem with the previous version and waited for the new one. Further details: I got errors of bad leapsecond values, so changed localtime to /dev/null. Changes in Makefile: LOCALTIME= US/Central TZDIR= /usr/local/zoneinfo LEAPSECONDS= /dev/null CFLAGS= -DSTD_INSPIRED -DUSG_COMPAT -DUSG # test -f /usr/bin/ranlib && ranlib $@ Changes to pacificnew: # Following four lines due to no PPET yet #Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE #Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S #Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S Rule Twilite 1987 max - Oct lastSun 2:00 0 S Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX consulting +1 612-825-2607 uunet!datapg!sewilco

1 0

Re: PD Localtime changes since v08i085?
by ado March 14, 1988

March 14, 1988

I've sent an updated version of the time conversion package to rsalz(a)uunet.uu.net; with providence it should appear in comp.sources.unix shortly. --ado

1 0

PD Localtime changes since v08i085?
by emoryu1!gatech!rutgers!datapg.mn.org!sewilco March 14, 1988

March 14, 1988

Were there any changes to the PD "localtime" since the version posted in mod.sources as v08i085 on 28 Feb 87? It's time to use it, and I need to know if there were bugs found. I don't see any updates in the archive listings. The only change which I found so far was changing the "pacificnew" entries from type "uspres" and "nonpres" to a single type "-" entry. According to the Department of Transportation, no version of the Presidential Election Time became law. Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress C and UNIX consulting +1 612-825-2607

1 0

time zone functions in January 11, 1988 draft C standard
by ado Feb. 17, 1988

Feb. 17, 1988

Little in the way of change to time functions in the January 11, 1988 draft C standard. Recall that the last draft said, in the main text, this about the tm_isdst element of the struct tm structure: The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available. It later described the new "mktime" function for converting a struct tm back into a time_t value, noting in a footnote that A positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time. Your correspondent sent a letter to the X3J11 committee, noting (among other things) that the above material was all well and good, but since it was in a footnote, \fIand since footnotes are not part of the Standard\fP, programmers would not be able to count on the above characteristics of mktime. Well, the good news is that X3J11 acted on this point. The other news is that they simply changed the footnote to read Thus, a positive or zero value for tm_isdst. . . This makes me realize just how feeble-minded I must be getting in my dotage. I didn't understand (and still don't understand) how the promise that "A negative value for tm_isdst causes [mktime] to attempt to determine whether [DST] is in effect. . ." is implied by the description of tm_isdst in the standard. (Actually, I'm unclear about both sentences in the footnote, but the second especially.) Maybe someone on the time zone mailing list will be able to set me clear before I again make a fool of myself in my next letter to the Committee? Other than the added "Thus," there were no time-related changes to section 4.12 of the draft. They did throw in a few "noalias"es and required that if you #include <time.h> then NULL and size_t will be defined for you. --ado

1 0

Help wanted in updating time zone information files
by ado Jan. 2, 1988

Jan. 2, 1988

I'm hoping to send some updated time zone information files to comp.sources.unix soon (as soon as I can learn the equation of time for 1988 and, with that information, do up the 1988 Riyadh table). I've attached a bundle of the new files that would be used in making the posting; I'd appreciate any corrections or additional information that folks might provide. Here's a summary of the changes these files reflect. Thanks to Guy Harris for providing the vast majority of the changes. * The "northamerica" file has information about Mexico and about DST being observed on Navajo lands within Arizona. * The "pacificnew" file has information on the status of H.R. 435 (the bill whose passage would necessitate use of the "pacificnew" stuff). * The "southamerica" file is completely new. * The "asia" file is almost completely new; it now covers both Chinas and the Republic of Korea. --ado : To unbundle, sh this file echo 'northamerica' 1>&2 cat >'northamerica' <<'End of northamerica' # @(#)northamerica 3.4 # US Daylight Saving Time ended on the last Sunday of *October* in 1974. # See, for example, the front page of the Saturday, October 26, 1974 # and Sunday, October 27, 1974 editions of the Washington Post. # Note also this from seismo!munnari!kre: # "I recall also being told by someone once that Canada didn't have # the DST variations in 74/75 that the US did, but I am not nearly # sure enough of this to add anything." # The above has been confirmed by Bob Devine; we'll go with it here. # Before the Uniform Time Act of 1966 took effect in 1967, observance of # Daylight Saving Time in the US was by local option, except during wartime. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 max - Apr Sun>=1 2:00 1:00 D ############################################################################### # New names # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Eastern -5:00 US E%sT Zone US/Central -6:00 US C%sT Zone US/Mountain -7:00 US M%sT Zone US/Pacific -8:00 US P%sT Zone US/Yukon -9:00 US Y%sT # Mainland US areas that are always Standard as of 1986. Zone US/East-Indiana -5:00 US E%sT 1946 -5:00 - EST # Always EST as of 1986 Zone US/Arizona -7:00 US M%sT 1946 -7:00 - MST # Always MST as of 1986 # However. . .a writer from the Inter Tribal Council of Arizona, Inc., # notes in private correspondence dated 12/28/87 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." Link US/Mountain Navajo # And then there's Hawaii. # DST was observed for one day in 1933; # Standard time was change by half an hour in 1947; # it's always standard as of 1986. Zone US/Hawaii -10:30 US H%sT 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 1 2:00 -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Old names, for S5 users # Link LINK-FROM LINK-TO Link US/Eastern EST5EDT Link US/Central CST6CDT Link US/Mountain MST7MDT Link US/Pacific PST8PDT Link US/East-Indiana EST Link US/Arizona MST Link US/Hawaii HST ################################################################################ # Canada is reportedly lots easier than the US--leastways since 1951. # I don't know what they did before then. # 4.3BSD claims that it's perfectly regular. # According to a posting in "comp.bugs.misc", "comp.unix.wizards", etc. # on February 8, 1987, by Dave Sherman of the Law Society of Upper Canada, # "...Canada (well, Ontario and at least some of the other provinces) are # adopting the new daylight savings time rules...". We assume all of # Canada is doing so. # 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 Rule Canada 1987 max - Apr Sun>=1 2:00 1:00 D # 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 Zone Canada/Yukon -9:00 Canada Y%sT ################################################################################ # Mexico # Rules are from the Official Airline Guide, Worldwide Edition, for 1987. # Rules prior to 1987 are unknown. # The comments in the OAG say "Only Ensenada, Mexicale, San Felipe and Tijuana # observe DST." This is presumably Baja California Norte, above 28th parallel, # as listed there; Mexico/BajaSur is for "Baja California Sur and N. Pacific # Coast (States of Sinaloa and Sonora)." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mexico 1987 max - Oct lastSun 2:00 0 S Rule Mexico 1987 max - Apr Sun>=1 2:00 1:00 D # 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 End of northamerica echo 'pacificnew' 1>&2 cat >'pacificnew' <<'End of pacificnew' # @(#)pacificnew 3.4 # The U.S. House of Representatives passed a bill (H.R. 435) establishing # "Pacific Presidential Election Time" on November 10, 1987; # it has yet (as of January 2, 1988) been approved by the U.S. Senate # or signed into law by the U.S. President. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Twilite 1987 max - Apr Sun>=1 2:00 1:00 D Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Pacific-New -8:00 US P%sT 1987 -8:00 Twilite P%sT End of pacificnew echo 'southamerica' 1>&2 cat >'southamerica' <<'End of southamerica' # @(#)southamerica 1.1 # From Official Airline Guide - Worldwide Edition (1987). Countries not # listed here do not observe DST, according to the OAG. Time zone names # are pure inventions, and none are supplied for countries not observing # DST; updates from natives would be appreciated. The times that DST # starts and ends are based on the assumption that they switch a 2AM just # as everybody else does. # Brazil # The OAG lists October 25, 1987 and February 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year". We # infer a rule here from one example, always a dangerous practice.... Yes, # they really do switch on Saturday, according to the OAG. # "Brazil/Acre" is for the Territory of Acre; "Brazil/DeNoronha" is for # Fernando De Noronha. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Brazil 1987 max - Feb Sat<=14 2:00 0 S Rule Brazil 1987 max - Oct Sat<=28 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Brazil/East -3:00 Brazil E%sT Zone Brazil/West -4:00 Brazil W%sT Zone Brazil/Acre -5:00 Brazil A%sT Zone Brazil/DeNoronha -2:00 Brazil F%sT # Chile # The OAG lists October 11, 1987 and March 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1987 max - Mar Sun<=14 2:00 0 S Rule Chile 1987 max - Oct Sun<=14 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Chile/Continental -4:00 Chile C%sT Zone Chile/EasterIsland -6:00 Chile E%sT End of southamerica echo 'asia' 1>&2 cat >'asia' <<'End of asia' # @(#)asia 3.3 # Incorporates data for Singapore from Robert Elz' asia 1.1, as well as # additional information from Tom Yap, Sun Microsystems Intercontinental # Technical Support (including a page from the Official Airline Guide - # Worldwide Edition). The names for time zones are guesses. # People's Republic of China. Yes, they really have only one time zone. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule PRC 1970 max - Apr Sun<=14 2:00 1:00 D Rule PRC 1970 max - Sep Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone PRC 8:00 PRC C%sT # Republic of Korea. According to someone at the Korean Times in San Francisco, # Daylight Savings Time was not observed until 1987. He did not know # at what time of day DST starts or ends. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ROK 1987 max - May Sun<=14 2:00 1:00 D Rule ROK 1987 max - Oct Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone ROK 9:00 - KST 1987 9:00 ROK K%sT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Japan 9:00 - JST Zone Singapore 8:00 - SST Zone Hongkong 8:00 - HKT Zone ROC 8:00 - CST # Israel # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Israel 1987 max - Apr Sun<=21 2:00 1:00 D Rule Israel 1987 max - Aug Sat<=28 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 3:00 Israel I%sT End of asia exit

1 0

New draft C standard
by ado Nov. 21, 1987

Nov. 21, 1987

I got the latest, November 9, 1987 draft C standard in the mail yesterday. The good news: there's a footnote telling how to get a broken-down wall clock time converted into "elapsed seconds since the epoch" (or whatever the implementation is choosing to use) *without* having to know whether the time being converted is Daylight Time or not: you're supposed to drop a -1 into the "tm_isdst" field. The bad news: this mechanism is described in a footnote, and, unfortunately, footnotes are not part of the Standard (as is explained at the start of the Standard). (There's other stuff relegated to footnotes that might better be made part of the Standard, but that's a different soapbox.) Giving a choice of lobbying to get the footnote's content moved into the Standard or dropping mktime entirely, I'd choose the second alternative, but I realize I'm getting crabbier as I get older. I've attached a transcribed version of the latest wording. --ado 4.12 DATE AND TIME <time.h> 4.12.1 Components of time The header <time.h> declares one macro, three types, and several functions for manipulating time. Many functions deal with a calendar time that represents the current date (according to the Gregorian calendar) and time. Some functions deal with local time, which is the calendar time expressed for some specific time zone, and with Daylight Saving Time, which is a temporary change in the algorithm for determining local time. The local time zone and Daylight Saving Time are implementation defined. The macro defined is CLK_TCK which is the number per second of the value returned by the clock function. The types declared are clock_t and time_t which are arithmetic types capable of representing times, and struct tm which holds the components of a calendar time, called the broken-down time. The structure shall contain at least the following members, in any order. The semantics of the members and their normal ranges are expressed in the comments. int tm_sec; /* seconds after the minute - [0,59] */ int tm_min; /* minutes after the hour - [0,59] */ int tm_hour; /* hours since midnight - [0,23] */ int tm_mday; /* day of the month - [1,31] */ int tm_mon; /* months since January - [0,11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday - [0,6] */ int tm_yday; /* days since January 1 - [0,365] */ int tm_isdst; /* Daylight Saving Time flag */ The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available. 4.12.2 Time manipulation functions 4.12.2.1 The clock function [SECTION OMITTED] 4.12.2.2 The difftime function [SECTION OMITTED] 4.12.2.3 The mktime function Synopsis #include <time.h> time_t mktime(struct tm *timeptr); Description The mktime function converts the broken-down time, expressed as local time, in the structure pointed to by timeptr into a calendar time value with the same encoding as that of the values returned by the time function. The original values of the tm_wday and tm_yday components of the structure are ignored, and the original values of the 101 other components are not restricted to the ranges indicated above. On successful completion, the values of the tm_wday and tm_yday components of the structure are set appropriately, and the other components are set to represent the specified calendar time, but with their values forced to the ranges indicated above; the final value of tm_mday is not set until tm_mon and tm_year are determined. Returns The mktime function returns the specified calendar time encoded as a value of type time_t. If the calendar time cannot be represented, the function returns the value (time_t)-1. Example What day of the week is July 4, 2001? #include <stdio.h> #include <time.h> static const char *const wday[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "-unknown-" }; struct tm time_str; time_str.tm_year = 2001 - 1900; time_str.tm_mon = 7 - 1; time_str.tm_mday = 4; time_str.tm_hour = 0; time_str.tm_min = 0; time_str.tm_sec = 1; time_str.tm_isdst = -1; if (mktime(&time_str) == -1) time_str.tm_wday = 7; printf("%s\n", wday[time_str.tm_wday]); 4.12.2.4 The time function Synopsis #include <time.h> time_t time(time_t *timer); Description The time function determines current calendar time. The encoding of the value is unspecified. Returns The time function returns the implementation's best approximation to the current calendar time. The value (time_t)-1 is returned if the calendar time is not available. If timer is not a null pointer, the return value is also assigned to the object it points to. ____________ 101. A positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time.

1 0

Re: August 13 C Standard Rationale on mktime
by ado Sept. 1, 1987

Sept. 1, 1987

> . . .the sole purpose of mktime is for doing arithmetic on time_t's. . . > if the caller has to set tm_isdst before calling mktime(). > The use that most people want for mktime() is to be able to parse > a string (or whatever) into the tm_hour fields, etc, and then produce > a time_t .. having to second guess whether dst applied at that particular > time is never going to work. . . Well, much of the time it will work if you're prepared to check the values that mktime drops into the "struct tm" passed to it, and if you've saved away the values you passed in. You guess one way or the other on tm_isdst and call mktime. If mktime changes tm_hour on you, you guess "the other" way and try again. Second guessing, yes; third guessing, no. Of course the Standard is mum about the need to do this, and about the need to handle other problems mentioned by kre. --ado

1 0

August 13 C Standard Rationale on mktime; seismo's retirement
by ado Sept. 1, 1987

Sept. 1, 1987

The attached material appears on pages 99 and 100 of the 13 August 1987 "Rationale for Draft Proposed American National Standard for Information Systems Programming Language C". Note that mktime is supposed to examine tm_isdst when converting a "struct tm" to a "time_t". Coding errors in previous versions of the Rationale have also been corrected, although I believe that the when = *localtime(now); line should read when = *localtime(&now); Seismo's retirement from the mail forwarding business makes it unlikely that the time zone mailing list can be continued; this should not be a problem since volume has been nonexistent of late. If all else fails, try comp.std.c. --ado 4.12.2.3 The mktime function mktime was invented by the Committee to complete the set of time functions. With this function it becomes possible to perform portable calculations involving clock times and broken-down times. The rules on the ranges of the fields within the *timeptr record are crafted to permit useful arithmetic to be done. For instance, here is a paradigm for continuing some loop for an hour: #include <time.h> struct tm when; time_t now; time_t deadline; /* ... */ now = time(0); when = *localtime(now); when.tm_hour += 1; /* result is in the range [1,24] */ deadline = mktime(&when); printf("Loop will finish: %s\n", asctime(&when)); while (difftime(time(0), deadline) > 0) whatever(); The specification of mktime guarantees that the addition to the tm_hour field produces the correct result even when the new value of tm_hour is 24, i.e., a value outside the range ever returned by a library function in a struct tm object. One of the reasons for adding this function is to replace the capability to do such arithmetic which is lost when a programmer cannot depend on time_t being an integral multiple of some known time unit. Several readers of earlier versions of this Rationale have pointed out apparent problems in this example if now is just before a transition into or out of daylight saviings time. However, when.tm_isdst tags what sort of time was the basis of the calculation. Implementors, take heed.

2 1

Re: Timezone stuff and System V Verification Suite
by ado Aug. 7, 1987

Aug. 7, 1987

The problem at hand: the mod.sources version of the time zone compiler sets tzname[1] to "EWT" for the Eastern US; this causes problems with SVVS. I had a realization this morning. A while back I added a "-s" flag to the time zone compiler to let folks produce time zone information files with whose time(2) values were limited to numbers that have the same value whether you take them to be signed or unsigned. This was done to let time zone files be used in network setups where some machines on the network wanted to have signed time_t's and others wanted to have unsigned time_t's. Providentially, if you use the -s option you should get files that let localtime be SVVS compliant. Not only is this in line with kre's suggestion that the work should be done in the compiler rather than in localtime--it's already in place. I've attached diffs for zic.c and zic.8; apologies to those who've seen them before (but note that I've added a new note about SVVS to zic.8). --ado ------------------------------------------------------------------------------- *** 3.1/zic.c Fri Aug 7 10:42:22 1987 --- 3.6/zic.c Fri Aug 7 10:42:39 1987 *************** *** 4,10 **** #ifndef lint #ifndef NOID ! static char sccsid[] = "@(#)zic.c 3.1"; #endif /* !NOID */ #endif /* !lint */ --- 4,10 ---- #ifndef lint #ifndef NOID ! static char sccsid[] = "@(#)zic.c 3.6"; #endif /* !NOID */ #endif /* !lint */ *************** *** 355,361 **** usage() { (void) fprintf(stderr, ! "%s: usage is %s [ -v ] [ -l localtime ] [ -d directory ] [ filename ... ]\n", progname, progname); exit(1); } --- 355,361 ---- usage() { (void) fprintf(stderr, ! "%s: usage is %s [ -s ] [ -v ] [ -l localtime ] [ -d directory ] [ filename ... ]\n", progname, progname); exit(1); } *************** *** 362,367 **** --- 362,368 ---- static char * lcltime = NULL; static char * directory = NULL; + static int sflag = FALSE; main(argc, argv) int argc; *************** *** 374,380 **** umask(umask(022) | 022); #endif progname = argv[0]; ! while ((c = getopt(argc, argv, "d:l:v")) != EOF) switch (c) { default: usage(); --- 375,381 ---- umask(umask(022) | 022); #endif progname = argv[0]; ! while ((c = getopt(argc, argv, "d:l:vs")) != EOF) switch (c) { default: usage(); *************** *** 401,406 **** --- 402,410 ---- case 'v': noise = TRUE; break; + case 's': + sflag = TRUE; + break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) usage(); /* usage message by request */ *************** *** 465,470 **** --- 469,476 ---- tt_signed = FALSE; min_time = 0; max_time = ~(time_t) 0; + if (sflag) + max_time >>= 1; } else { tt_signed = TRUE; min_time = bit; *************** *** 471,476 **** --- 477,484 ---- max_time = bit; ++max_time; max_time = -max_time; + if (sflag) + min_time = 0; } min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; *************** *** 687,693 **** inrule(fields, nfields) register char ** fields; { ! struct rule r; if (nfields != RULE_FIELDS) { error("wrong number of fields on Rule line"); --- 695,701 ---- inrule(fields, nfields) register char ** fields; { ! static struct rule r; if (nfields != RULE_FIELDS) { error("wrong number of fields on Rule line"); *************** *** 757,763 **** register char ** fields; { register char * cp; ! struct zone z; register int i_gmtoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; --- 765,771 ---- register char ** fields; { register char * cp; ! static struct zone z; register int i_gmtoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; ------------------------------------------------------------------------------- *** 3.1/zic.8 Fri Aug 7 10:41:29 1987 --- 3.4/zic.8 Fri Aug 7 10:41:32 1987 *************** *** 12,17 **** --- 12,19 ---- .B \-l .I localtime ] [ + .B \-s + ] [ .I filename \&... ] .SH DESCRIPTION *************** *** 43,48 **** --- 45,55 ---- of years representable by .IR time (2) values. + .TP + .B \-s + Limit time values stored in output files to values that are the same + whether they're taken to be signed or unsigned. + You can use this option to generate SVVS-compatible files. .sp Input lines are made up of fields. Fields are separated from one another by any number of white space characters. *************** *** 98,104 **** field. .TP .B TYPE ! Gives the type of year in which the year applies. If .B TYPE is --- 105,111 ---- field. .TP .B TYPE ! Gives the type of year in which the rule applies. If .B TYPE is *************** *** 155,161 **** field. .TP .B AT ! Gives the time of day at which the rule takes affect. Recognized forms include: .nf .in +.5i --- 162,168 ---- field. .TP .B AT ! Gives the time of day at which the rule takes effect. Recognized forms include: .nf .in +.5i *************** *** 291,294 **** /etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .. @(#)zic.8 3.1 --- 298,301 ---- /etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .. @(#)zic.8 3.4

1 0

Re: Timezone stuff and System V Verification Suite
by seismo!scubed!ncr-sd!ncrcae!sauron!wescott July 24, 1987

July 24, 1987

> I think the "right" fix is to remove the "Link" lines from the > "northamerica" file (which provides the EST5EDT aliases) and > put them in the "systemv" file, where the data should be an > accurate System V emulation. > ... > Or perhaps the "blessed" 2 zone names should be marked in the > data file to avoid surprises. That's an idea. We (NCR) are really looking for the best of both worlds. We like the flexibility of the PD ctime but need to pass the SVVS as well as provide compatibility for existing customers. The only problem has been that of tzname(). > Both the Sys V and BSD standard timezone name stuff is trash, > it all needs to be discarded completely. And the matter gets worse with SysVr3v1 (from ctime(3c) man page): [start of quote] tzset() uses the contents of the environment variable TZ to override the value of the different external variables. The syntax of TZ can be described as follows: TZ -> zone | zone signed_time | zone signed_time zone | zone signed_time zone dst zone -> letter letter letter signed_time -> sign time | time time -> hour | hour : minute | hour : minute : second dst -> signed_time | signed_time ; dst_date , dst_date | ; dst_date , dst_date dst_date -> julian | julian / time [...] For example, the setting for New Jersey in 1986 could be "EST5EDT4;117/2:00:00,299/2:00:00" [...] A southern hemisphere setting such as the Cook Islands could be "KDT9:30KST10:00;64/5:00,303/20:00" [end of quote] There is a new extern long to go along with timezone called "altzone" which holds the value of the daylight saving time "timezone" offset. The SVID, however, does not reflect this "improvement" nor apparently will the SVVS. The "Future Directions" section of the SVID does mention the fractional hours/sign component in the middle of the TZ variable. The ctime(3c) man page also describes two new routines that allow user control of the formatting of the string as well as using non-english names (under the control of the env. var. LANGUAGE). -Mike Wescott wescott(a)ncrcae.Columbia.NCR.COM

2 1

Timezone stuff and System V Verification Suite
by ado July 19, 1987

July 19, 1987

Here are excerpts from two notes from Mike Wescott (wescott(a)ncrcae.Columbia.NCR.COM) I'd appreciate comments on the changes Mike suggests. (Lines preceded by "> " in the second note are Mike quoting me.) --ado Date: Thu, 9 Jul 87 15:29:36 pdt Message-Id: <8707092229.AA00730(a)SCUBED.ARPA> Subject: Re: v08i085: Public Domain localtime We have uncovered a problem with the PD ctime with respect to the System V Verification Suite and SVID compatibility. The problem is with tzset(). Try the little program, xxx.c: #include <time.h> main() { tzset(); printf("%s\n%s\n", tzname[0], tzname[1]); } and try the following: TZ=PST8PDT ./xxx it produces: PST PWT and TZ=EST5EDT ./xxx produces EST EWT The problem is that tzname[1] become the (obsolete) EWT. The fix, I believe, would be to use the most recently used abbreviations to the value of time(0). Diff for such a fix follows and passes SVVS. -Mike Wescott wescott(a)ncrcae.Columbia.NCR.COM *** localtime.c.or Thu Jul 9 09:57:27 1987 --- localtime.c Thu Jul 9 14:31:38 1987 *************** *** 90,95 **** --- 90,96 ---- { register int i; register int fid; + time_t now; if (name == 0 && (name = TZDEFAULT) == 0) return -1; *************** *** 182,191 **** timezone = -s.ttis[0].tt_gmtoff; daylight = 0; #endif /* USG_COMPAT */ ! for (i = 1; i < s.typecnt; ++i) { register struct ttinfo * ttisp; ! ! ttisp = &s.ttis[i]; if (ttisp->tt_isdst) { tzname[1] = &s.chars[ttisp->tt_abbrind]; #ifdef USG_COMPAT --- 183,194 ---- timezone = -s.ttis[0].tt_gmtoff; daylight = 0; #endif /* USG_COMPAT */ ! now = time(0); ! for (i = 1; i < s.timecnt; ++i) { register struct ttinfo * ttisp; ! if (now < s.ats[i]) ! break; ! ttisp = &s.ttis[s.types[i]]; if (ttisp->tt_isdst) { tzname[1] = &s.chars[ttisp->tt_abbrind]; #ifdef USG_COMPAT ------------------------------------------------------------------------------- Date: Tue, 14 Jul 87 07:22:19 pdt Message-Id: <8707141422.AA27049(a)SCUBED.ARPA> Subject: Re: v08i085: Public Domain localtime > Many thanks for the note on the problem with SVVS. > Would it be all right with you if I passed the note on to other interested > folks? No problem, I sent it to you with that in mind. The code could probably be made a little more efficient but it shouldn't have to run too often. > Also--the time zone files described in the "systemv" file were designed to > provide System V compatibility. It looks as if you're in a position to check > on whether they actually do; if you could, I'd appreciate it. We ran SVVS (SysVr2 not r3 yet) and the only thing it complained about was the problem with the tzset() function. We are compiling with USG, USG_COMPAT, and STD_INSPIRED defined. I'll check the "systemv" file but it doesn't seem to be problem as far as SVVS goes.

2 1

Re: what should be in POSIX vs X3J11
by seismo!celerity!dreamit!jjw May 19, 1987

May 19, 1987

In response to mail from seismo!nbires!vianet!devine Sat May 9 10:19:15 1987 > In my last message I proposed dividing the many date/time related > functions by the rule of 'is it Unix-based or language-based?'. And I > meant by a call being in Man Section 3 as roughly the same as the latter. I don't think the division should be based on whether the function is documented in section 2 or 3 of the Unix manual, that is mostly an artifact of the Unix implementation. Instead, Something should be placed into X3J11 based on whether a standard conforming C program should be able to use the function. Something should be placed into the POSIX standard based on whether all programs running under a conforming operating system should be able to use the function. In general I think POSIX should restrict itself to low level functions (such as "time()") and should avoid specifying higher level functions (such as "ctime()"). X3J11, however, should specify both low and high level functions where that makes sense. Because of the relationship between C and Unix there will be a lot of overlap between these two and every effort should be made to keep them the same. I believe this mailing list is a reasonable place to discuss whether the various timing functions belong in X3J11, POSIX or both. It will then be up to those who are members of the standards committees to bring any results of such a discussion to the attention of the committees. I would organize "time" functions as follows: POSIX only both X3J11 only stime() time()** everything else utime()* times() time_t The reason for leaving stime() out of X3J11 is that setting a system wide time and date is not something that is done by many programs and The reason for leaving utime() out of X3J11 is that the implications of and reasons for setting file times is likely to be operating systems dependant. It is also possible to argue that if programs can read these values they should be able to set them too. * file access times (what they are and when they are set) is probably outside the purview of this mailing list. ** POSIX should probably have a "gettimeofday" call which provides better granularity than seconds. ftime() has the problem of including timezone information which I don't believe belongs in the operating system interface. -- J. J. Whelan

1 0

Colorado DST info
by seismo!nbires!vianet!devine May 19, 1987

May 19, 1987

The full state House has passed a resolution to have year-round DST for Colorado. The proposal to move the state to Central time was defeated. Basically, the argument against this second proposal boiled down to "This state has mountains. Why should we move out of the Mountain timezone?". The State Senate must approve the resolution before the US Dept of Transportation will be asked to approve it. Bob

1 0

POSIX & X3J11
by seismo!meccts.mecc.mn.org!ahby May 11, 1987

May 11, 1987

In a recent posting, Mark notes that this group has no real pull with either standards body, and that they will decide what they decide. Well, although I cannot speak for X3J11 (I am a voting member, but do not have time to attend the meetings), I can say that IEEE P1003.1 is always interested in any contributions that ANY group or individual cares to make. I have been recording most of the discussion about what items you think should be where, and I am willing to submit these to the Working Group for consideration at the June meeting in Seattle. However, time is short! (no pun intended). The June meeting is the 22nd, and that is the LAST meeting before full ballot will take place. Although anyone may comment after the standard goes to ballot, balloting objections will get first consideration after we go full use ballot. Right now, all comments are being considered. I know the reasons why the time stuff was dropped from the draft some meetings ago (I believe it was in September), and personally think that they were not good reasons. I believe that the group would really welcome a formal propsal with specific language for some time functions. I strongly recommend that some or all of the people on this mailing list get together and draft such a proposal. --- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby(a)MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute

1 0

Re: what should be in POSIX vs X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 10, 1987

May 10, 1987

I guess I have a fundamental problem with this whole discussion. This mailing list is not, as far as I know, officially sanctioned by either X3J11 or P1003. We can pontificate all we want about what belongs in ANSI C or in POSIX, but these decisions are made by X3J11 and P1003, not by us. Other than being interested in time zone issues, do we really have any kind of sanction, delegation, or authority from either committee? Mark

1 0

Re: what should be in POSIX vs X3J11
by seismo!nbires!vianet!devine May 9, 1987

May 9, 1987

Unix and C are very tightly interwoven. Trying to separate them to form two standards is very much a Gordian (Ritchian?) Knot. In my last message I proposed dividing the many date/time related functions by the rule of 'is it Unix-based or language-based?'. And I meant by a call being in Man Section 3 as roughly the same as the latter. This message has more detail. Putting the choices into columns: Unix-based either-one language-based time() ftime() asctime() times() tzset() ctime() stime() time_t gmtime() utime() localtime() difftime() mktime() struct tm X3J11's date formatting functions Do these groupings make sense? Where should the 'either-one' functions be placed? Arguments can be made for putting them on both ends of the spectrum. Here are a couple of examples to show how various vendors with wildly different OSs dealt with the problem of what to put in their C libraries. VMS: Base OS has a 64-bit representation of time that is the number of 100 nanoseconds periods since 00:00 on November 17, 1858. HAS: ctime(), ftime() [but TZ and DST are zero], localtime() [isdst=0] time() [seconds since 00:00 UT 1/1/70], and times() [the sys fields=0] MISSING: asctime(), gmtime(), stime(), utime() DOS: Base OS keeps track of time since 1/1/80 HAS: asctime(), ctime(), difftime(), ftime(), gmtime(), localtime(), tzset(), time() [returns seconds since 00:00 UT 1/1/70], utime(), and times() MISSING: stime() DOS's functions won't give back a formatted string for any time before 1/1/80, ie, long t=12345; ctime(&t) gives back 1/1/80 even though t is referring to a day in 1970.

1 0

Re: what should be in POSIX vs X3J11
by seismo!sun!guy May 6, 1987

May 6, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. This isn't an adequate definition of a "C library function". "getpwent" is in section 3 of some UNIX manuals, but it is definitely not a C function. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. I wouldn't bet on that. There may have to be some equivalent procedure; Pascal doesn't *have* any date/time manipulation functions. Frankly, I don't think C should have them, either. The standard UNIX library is called the "C library", but this is a misnomer. It contains some functions that may be considered language support for C, some functions that can be considered part of the operating system, and some functions that are really just useful utilities. The Standard I/O library routines are probably best considered to be language support for C (one might also consider them to be part of the operating system, except that the same interfaces have been implemented under other operating systems, and the intent seems to be that all C implementations should have those routines). "open" is clearly part of the operating system, as is "getpwent". "lsearch" is clearly just a utility; the code for "lsearch" could be transplanted to another OS with no trouble (except for possibly writing a "memcpy" routine), and could also be rewritten in any other language that supports the requisite data types. Neither POSIX nor X3J11 includes "lsearch". Although this means that portable code can't use it (or other potentially more interesting utility routines), this is arguably the correct thing to do. However, X3J11 includes some routines that could be considered utility routines or operating system interfaces. The date/time conversion routines fall into these categories: If the format of a "time_t" is considered to be a characteristic of the operating system (since, in most cases, it is the OS that supplies date/time information), "localtime" and "gmtime" are really operating system interfaces. "asctime" is clearly a utility, since it can be expressed in any sufficiently expressive language in an operating-system independent fashion (note that, in fact, a portable implementation of "asctime" is published as part of the current X3J11 draft!). The same is true of "ctime" (for which a portable implementation is also published). "strftime" could also be considered a utility routine, except that it is dependent on the "locale", which is currently considerered part of the C environment. As long as the "locale" is considered part of the C environment, and *not* a part of the operating system, "strftime" should be a part of the C standard. If the ANSI C standard included a definition of low-level routines for obtaining, say, the locale's full name for a month, given a month number of that month, "strftime" could also be written in portable ANSI C and published in the X3J11 draft. It does not include any OS dependencies. I would argue that this sort of "internationalization" belongs neither in an OS standard nor in a language standard; there should be a separate standard which, like e.g. various graphics standards, has bindings for several languages and can be implemented under various OSes. I'm not sure *where* the time-related stuff (i.e., the stuff that deals with "struct tm" values) belongs, although I'd argue in favor of putting it in POSIX. Unfortunately, I don't think the time-related and internationalization stuff is going to be moved out of ANSI C, and I'm also not sure how to split the OS-related and internationalization-environment-related time handling stuff between POSIX and some C-language or other-language binding of an internationalization standard.

1 0

what should be in POSIX vs X3J11
by seismo!nbires!vianet!devine May 5, 1987

May 5, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. The difficult part is how to define how the Posix utilities (eg. date, and ls) use and display dates. This is an issue for one of the POSIX subgroups (dot 2?) not the core group. Bob Devine

1 0

Re: X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 5, 1987

May 5, 1987

It sounds to me like we're all in agreement: a field in the struct tm defining the offset from GMT is what we need. Whether you call it an "adjustment" or an "offset" is just your point of view. Mark

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 5, 1987

May 5, 1987

> That is why we NEED the tm_tzadj member added to the tm structure. > >I'm not sure I follow how this follows. I agree that a tm_zone >(ie: what zone this time was converted from) is needed, but I >don't see the need for a separate time zone adjustment field. We are agreeing. There is the need for a member (whether the name is tm_zone or tm_adj as it is in HP's implementation) in the tm structure which gives the difference between GMT and localtime in seconds. This applies specifically to the time value in the tm structure. Sorry about any confusion. Ron Tolley

1 0

Re: X3J11
by Robert Elz May 5, 1987

May 5, 1987

Date: Mon, 4 May 87 11:04:30 EDT From: hplabs!hpfcla!hpfclj!hpfcdg!rgt Message-ID: <8705041525.AA23780@hpfcla> That is why we NEED the tm_tzadj member added to the tm structure. I'm not sure I follow how this follows. I agree that a tm_zone (ie: what zone this time was converted from) is needed, but I don't see the need for a separate time zone adjustment field. That is, I can't see anything rational for it to be an adjustment from. I don't believe the concept of a "standard zone" makes any sense, in general there simply is no such thing. The only number of consequence is the offset from gmt of this particular struct tm. kre

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 4, 1987

May 4, 1987

> The problem with all this is that mktime is supposed to be the > inverse of localtime, if it was the inverse of gmtime, or if it > had a zone parameter, then this kind of thing could be made to > work. But then mktime would be useless for more common functions, > especially that of hiding the timezone & dst rules from the application. Thank you for stating it so well. That is why we NEED the tm_tzadj member added to the tm structure. Ron Tolley

1 0

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 3, 1987

May 3, 1987

I thought the idea behind POSIX requiring X3J11 was that it eliminated duplication (and possible conflict) between X3J11 and POSIX. If POSIX isn't going to require X3J11, what will they overlay upon? K&R is the only other well known standard, and it's not only incredibly old, but the C library it documents is very incomplete even by 1978 standards. (I have a table I can send out if people are interested.) A lot of stuff was taken out of the /usr/group document because it was already in X3J11; does P.1003 really want to put all that stuff back in? Mark

2 1

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

To prevent runaway definitional anarchy, if POSIX includes some C language interface definitions, then oneof(X3J11,POSIX) should defer to the other. I think that POSIX deferring to X3J11 is natural, and should be done unless X3J11 gets really out of hand. Which I don't really think has happened yet. Joe

1 0

Re: Ballot 4 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

> I was just rereading ANSI C X3J11 and noticed that strftime and mktime > are in there. Since POSIX is a superset (by definition) of ANSI C, I should mention that even though X3J11 isn't final, and POSIX is co-operating strongly with (but not subservient to) X3J11, I wish to alter my ballot to support whatever is in X3J11, since it is or will be (it seems) the standard issued first (of the two). Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: Ballot 4 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

> POSIX will have strftime and mktime, it isn't an option. X3J11 is still a draft standard: it will go through (I hear tell) at least one more edit-RFC cycle. > Personally, I think strftime botches timezones - "hours" doesn't say > which time zone. Why, nor does ctime() at all, nor System V date. But there is, in the X3J11 strftime(), a %Z for the time zone. [ 10 Oct 1986 ] Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: Ballot 4 - results
by seismo!meccts.mecc.mn.org!ahby May 2, 1987

May 2, 1987

> I was just rereading ANSI C X3J11 and noticed that strftime and mktime > are in there. Since POSIX is a superset (by definition) of ANSI C, > POSIX will have strftime and mktime, it isn't an option. Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. X/OPEN had some reservations about POSIX requiring X3J11, because it would increase the time before there could be conforming systems. Also, a number of people from different implementors felt that when their companies had signed onto the POSIX concept, they had not necessarily bought into X3. These same people also said that they were planning on providing an X3 conforming environment, but not in the same timeframe as POSIX. As a result of these discussions, we redefined the terms CONFORMING APPLICATION and CONFORMING PORTABLE APPLICATION. The new names are PORTABLE APPLICATION USING EXTENSIONS and POSIX CONFORMING <language> APPLICATION. The text of these definitions is: Portable Application Using Extensions A Portable Application Using Extensions shall meet the following requirements: All extensions beyond those permitted to a Posix Conforming Language Application and the corresponding language shall be clearly documented. The application developer documents all application requirements for the operating environment that are implementation dependent including <limits.h> S2.9 characteristics and other related configuration requirements (linear address space, file store requirements, etc.) POSIX Conforming Applications POSIX Conforming Standard C Language Application A POSIX Conforming Standard C Language Application is a strictly conforming program, as defined in the ANSI/X3.159-198x standard, which utilizes only those extensions as described by the service bindings in this standard. In addition, a POSIX Conforming Standard C Language Application shall not depend on any unspecified, undefined, or implementation defined behavior, nor shall it require that any symbolic constant in <limits.h> S2.9 be outside its most restrictive value. As a result of these changes, it is possible to have a Conforming Implementation of POSIX that does not supply an X3 conforming environment. What environment it does provide is unspecified at this time, but the P1003.1 Working Group expects to see something from X/OPEN about a K&R C Language binding, which uses the X/OPEN Portability Guide as the basis for the C Language and its libraries. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. And since the POSIX Working Group decided at the December meeteing to defer to X3 in all things relating to time, the issue is a bit confused. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby(a)MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 Secretary, IEEE P1003.1

2 1

Re: X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 1, 1987

May 1, 1987

> Ignoring the coding and grammar errors in the Rationale, > the big problem here is that code like the Rationale's > > when = *localtime(now); > when.tm_hour += 1; > deadline = mktime(when); > > printf("Loop will finish: %s\n", asctime(when)); > while (difftime(time(0), deadline) > 0) whatever(); > > is *not* "a paradigm for continuing some loop for an hour." > The code may continue for two hours (or not at all) > if it is executed just before a daylight saving time transition. How? deadline is a time_t (GMT) and so is time(0). Mark

2 1

Re: X3J11
by ado May 1, 1987

May 1, 1987

> > . . .the big problem here is that code like the Rationale's > > > > when = *localtime(now); > > when.tm_hour += 1; > > deadline = mktime(when); > > > > printf("Loop will finish: %s\n", asctime(when)); > > while (difftime(time(0), deadline) > 0) whatever(); > > > > is *not* "a paradigm for continuing some loop for an hour." > > The code may continue for two hours (or not at all) > > if it is executed just before a daylight saving time transition. > How? deadline is a time_t (GMT) and so is time(0). (I hope I don't end up with egg all over my face on this one!) First, assume that it's 1:30:00 a.m. on a "spring forward" day when we execute the when = *localtime(now); statement. We next do a when.tm_hour += 1; which sets when.tm_hour to 2. We then execute the deadline = mktime(when); statement to answer the question "At what elapsed time in seconds since 1970 will my wall clock read 2:30 a.m.?" Since mktime knows we're springing forward, it returns -1 as a way of saying "There is no such time today." This means that the test in the while (difftime(time(0), deadline) > 0) whatever(); line will *always* succeed--so "whatever" will never be called. (Side questions: does this say anything about whether time_t should be signed? Does it say anything about extra checking difftime should do?) Now assume that it's 1:30:00 a.m. (for the first time :-) on a "fall back" day when we execute the when = *localtime(now); statement. Again we when.tm_hour += 1; deadline = mktime(when); to learn when our local wall clock will read 2:30 a.m. But that won't be until two hours from "now", so the loop will run twice as long as we might expect. --ado

1 0

Re: testing
by seismo!!dlm May 1, 1987

May 1, 1987

Yes, I am there I haven't seen or heard a word from the Time Mailing List in weeks! My mail address is {ihnp4,cbosgd,attunix,cbatt}!cuuxb!dlm. Maybe we're not polling cbosgd or cbatt but I thought so. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

mixed signed/unsigned systems; missing person; archives!?
by ado April 30, 1987

April 30, 1987

A while back I asked for ideas on how to set up time zone information files that could be shared (NFSwise, RFSwise, or otherwise) by machines that used signed time_t values (SVR2, BSD) and machines that used unsigned time_t values (those under Robert Elz's oversight, for example). Thanks to Chris Torek for pointing out the easy fix: limit the years that the file covers so that the only values filed are those for which it doesn't matter whether you interpret them to be signed or unsigned (values from 0 to 0x7fffffff on a VAX). I've added a few lines to the time zone compiler to do this; anyone interested in the lines should let me know. Missing persons department: Francisco Franco is still dead; Dennis Mumaugh is still missing. If you have a new address for either one, let me know. Astonishingly (to me, at least) I got a request for the mailing list "archives" today. So I bundled those letters that I had saved and sent them to the person making the request; I trust that there's not too much missing. And I've arranged for new items to be added to the archive automatically. All of which is a long way of saying that "time zone archives are available." (And of saying that "whenever you join a mailing list being handled by a novice mailing list handler, advise them to keep archives.") -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.CSS.GOV Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Re: Ballot 4 - results
by seismo!cbpavo.MIS.OH.ATT.COM!mark April 30, 1987

April 30, 1987

I was just rereading ANSI C X3J11 and noticed that strftime and mktime are in there. Since POSIX is a superset (by definition) of ANSI C, POSIX will have strftime and mktime, it isn't an option. Personally, I think strftime botches timezones - "hours" doesn't say which time zone. X3J11 says it's OK for gmtime to return NULL at run time if the operating system doesn't keep track of time zones! (Personally I'm a little tired of the timezone nonsense in MS DOS; some programs assume the clock/cal is GMT (those that use Microsoft C) and others local, so I have to set the TZ to EST0EDT to get all programs to work. Mark

1 0

Re: X3J11
by Arthur David Olson April 30, 1987

April 30, 1987

> I was just rereading ANSI C X3J11 and noticed that strftime and mktime > are in there. Since POSIX is a superset (by definition) of ANSI C, > POSIX will have strftime and mktime, it isn't an option. I'm hoping (against hope?) that the descriptions of strftime and mktime will be revised (or dropped from) X3J11. I've attached part of the letter I sent to the committee in early February. --ado > Standard, Page 152, Section 4.12.2.3 > Rationale, Page 95, Section 4.12.2.3 > > Ignoring the coding and grammar errors in the Rationale, > the big problem here is that code like the Rationale's > > when = *localtime(now); > when.tm_hour += 1; > deadline = mktime(when); > > printf("Loop will finish: %s\n", asctime(when)); > while (difftime(time(0), deadline) > 0) whatever(); > > is *not* "a paradigm for continuing some loop for an hour." > The code may continue for two hours (or not at all) > if it is executed just before a daylight saving time transition. > > Since the mktime function does not (and cannot) "replace the > capability to do [arithmetic] which is lost when a programmer cannot > depend on time_t being an integral multiple of some known time unit," > it should be dropped from the Standard (perhaps adding functions > to convert between time_t values and (long?) elapsed seconds since > the epoch--functions that will be extremely useful in converting > "old" software).

1 0

Ballot 4 - results
by seismo!nbires!vianet!devine April 28, 1987

April 28, 1987

>From devine Tue Apr 28 13:30 MDT 1987 To: nbires!seismo!elsie!tz Subject: Ballot #4 -- results Cc: devine Ballot #4 was to say if the following functions should be in Posix. YES maybe NO --- ----- -- 5 time_t time(time_t*) 5 char* ctime(time_t*) 5 struct tm* localtime(time_t*) 5 struct tm* gmtime(time_t*) 5 char* asctime(struct tm*) 3 1 1 void tzset() 1 1 3 int dysize(int) 1 2 2 int strftime(char*, int, char*, struct tm*) 1 4 int strfastime(char*, int, char*, struct tm*) 3 1 1 time_t mktime(struct tm*) --Bob Devine-------------- yes time_t time(time_t*) yes char* ctime(time_t*) yes struct tm* localtime(time_t*) yes struct tm* gmtime(time_t*) yes char* asctime(struct tm*) yes void tzset() no int dysize(int) no int strftime(char*, int, char*, struct tm*) no int strfastime(char*, int, char*, struct tm*) yes time_t mktime(struct tm*) We need a language- and conversion-independent function that converts a time_t value into a string. 'asctime()' is constrained by the requirement that its output fit into 26 chars. It also has the US format hard-coded into it. But, I don't think the strf* functions are sufficient. On 'mktime': I see a need for it. However, I am not willing to yet say "yes" until a working version of the code has been developed. I'll write a version in a month (or so)... -------------------------- --Arthur David Olson------ YES time_t time(time_t*) YES char* ctime(time_t*) YES struct tm* localtime(time_t*) YES struct tm* gmtime(time_t*) YES char* asctime(struct tm*) YES void tzset() NO int dysize(int) NO int strftime(char*, int, char*, struct tm*) NO int strfastime(char*, int, char*, struct tm*) NO time_t mktime(struct tm*) Whatever package is eventually standardized should be good enough that dysize isn't needed. strftime, strfastime, and mktime should not be standardized due to lack of existing art. -------------------------- --Ron Tolley-------------- yes time_t time(time_t*) yes int stime(time_t*) yes char* ctime(time_t*) yes struct tm* localtime(time_t*) yes struct tm* gmtime(time_t*) yes char* asctime(struct tm*) These functions are pretty much expected by everyone to be a part a UN*X implementation. If I came upon a system that did not have all of these functions, it wouldn't be UN*X to me. yes int strftime(char*, int, char*, struct tm*) POSIX means "Portable Operating Sytem ...". If portability ends at the borders of the U.S. then we are mistaken. These functions provide the ability to do international dates and date string formatting. This is especially true when the two are used together. For example, in the source for the pr command, the output of ctime is dissected to get the date for the page header. To print "Apr 17 09:57" in european languages is tricky enough, but try doing it in Japanese. I think that the field descriptors for strftime() are the best that I have seen, however I could argue that the similar nl_cxtime() and nl_ascxtime() from X/OPEN should be used instead because of "existing art". yes time_t mktime(struct tm*) yes int scanftime(struct tm*, int, char*, char*) These would be welcome additions. Until now getting from a user specified date value back to a struct tm* value and from there to a time_t value has been a black art. This should be stopped. I have actually never seen a proposal for scanftime() although I have one for strtotm() by Tom Osten as Document No. X3J11/87-215. Scanftime() would be the exact inverse of strftime(). It would take a string (char*) with an expected format (char*) of limited length (less that int) and fill what it could of the struct tm*. The number of characters actually parsed could be returned in int. The default would be to leave the values of unknown struct tm* members alone. By having a single standard parsing routine, much of the black art of date parsing could be eliminated. yes int settz(char*) yes int setlocale(char*) or nl_init(char *) All of the routines that have been mentioned so far should be influenced by two environment variables, TZ and LANG. In particular ctime(), localtime(), and mktime() should use the value of the TZ environment variable to determine the timezone adjustment or offset between local time and UT as appropriate. (A user modifiable table is _STRONGLY_ recommended. The results _MUST_ be uniform. Etc, etc, etc.) Similarly ctime(), asctime(), strftime(), and scanftime() or its equivalent should use the value of LANG to determine what the string format, month names, and other locale-dependent characteristics would be used. (Again tables should be used to map LANG values to actual characteristics.) Note that to ease the transition to using expecially the LANG environment variable, settz() called as settz(getenv("TZ")) and setlocale() called as setlocale(getenv("LANG")) (or the already implemented nl_init() from X/OPEN) should be used. Also that setlocale() will be used for many other things beside the time oriented functions. no int strfastime(char*, int, char*, struct tm*) As I recall, this is just a convenience for going from a char* string all the way to time_t*. That is not obvious from this expression. In any case it does not seem necessary. no void tzset() I have never seen a need to have this at all. The System V code that I have seen <comments about V.3 contract go here> always calls tzset() in localtime() anyway. no int dysize(int) I can take this one or leave it. It is only correct over its entire range. The year 1900 was NOT a leap year since it is divisible by 4 and 100 but not 400. (Check it out using the cal command.) [...] instead of strftime() and mktime(), we could use nl_ascxtime() and gmtime2() which are in current X/OPEN systems. (Gmtime2() is a static routine and does not account for local time but but is still "existing" art. I have been tempted to post it, but I reverse engineered it directly from the AT&T gmtime() code.) -------------------------- --Joe Yao----------------- Yes, simply because I have needed them at one or more times in my life: > time_t time(time_t*) > char* ctime(time_t*) > struct tm* localtime(time_t*) > struct tm* gmtime(time_t*) > char* asctime(struct tm*) > void tzset() > int dysize(int) > time_t mktime(struct tm*) I don't remember what these are supposed to do. If they are s'posed to emulate s5/Ultrix date +pattern, I don't think so. I really think that a call to localtime() and sprintf() would suffice. I am quite willing to be shown wrong. > int strftime(char*, int, char*, struct tm*) > int strfastime(char*, int, char*, struct tm*) -------------------------- --J. J. Whelan------------ From: scubed!sdcsvax!celerity!dreamit!jjw yes time_t time(time_t*) yes char* ctime(time_t*) yes struct tm* localtime(time_t*) yes struct tm* gmtime(time_t*) yes char* asctime(struct tm*) ?? void tzset() ?? int dysize(int) ?? int strftime(char*, int, char*, struct tm*) ?? int strfastime(char*, int, char*, struct tm*) yes time_t mktime(struct tm*) ?? means no opinion -------------------------- --Keith Bostic------------ > time_t time(time_t*) > char* ctime(time_t*) > struct tm* localtime(time_t*) > struct tm* gmtime(time_t*) > char* asctime(struct tm*) > void tzset() > int dysize(int) > int strftime(char*, int, char*, struct tm*) > int strfastime(char*, int, char*, struct tm*) > time_t mktime(struct tm*) I don't know what some of these do, so forgive any ignorance; time() should be replaced by something that gives you micro-second accuracy a la gettimeofday. The timezone stuff should be ripped out of gettimeofday, though, if it's used. Dysize() is silly. You didn't mention it, but if someone else does, tzsetwall doesn't appear useful. Harris/Olson/Elz have probably thought about this more than anyone else... --------------------------

1 0

ballots stopping for a while
by seismo!nbires!vianet!devine April 28, 1987

April 28, 1987

I won't send out ballot #5 for about a week. I simply don't have the time to do so over the next week and a half. If you have any topics that you want to see sent out in a ballot form, please send them to me. Finally, does anyone have the current mailing address for Dennis Mumaugh? He was last reachable as "dlm(a)cuuxb.ATT.COM". Send the update to Arthur Olson at elsie!tz-request. Bob Devine

1 0

Bad time on init ...
by seismo!hadron!jsdy April 22, 1987

April 22, 1987

> From: seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt > Message-Id: <8704142123.AA05061@hpfcla> > Date: Tue, 14 Apr 87 14:55:55 EST > Subject: Re: good news; missing person > [from me] > >That's what I thought, too. But because people were not setting the > >correct time before coming up multi-user, on a System V Rev 2 V 2.0, > >I put the little rc (bcheckrc?) that sets the date as the last thing > >before a single-user shell, as well as the first thing after. Now I > >get calls that the time is not set properly by this ... I haven't yet > >investigated this properly, but it seems that the TZ is lacking here > >somewhere. [ the exact nature of the problem hadn't come across right, yet. ] > The correct place to set TZ is in init. I have toyed with the idea of > adding a new type of line to inittab which can be used to set TZ in init > so that all of init's children can know about TZ. This was actually n o t the problem. If TZ is not set, the new code just looks at "localtime", and reads that. I should have remembered that, and interpreted the statement of the problem in light of that. The r e a l problem was that when anyone tried to s e t the time (at init or otherwise), it came up 10 hours off! When I finally got this statement of the problem, the actual location of the problem was obvious. You know it, too, when you know that we are in the US Eastern time zone, at -5 hours (+18000 Unix seconds) from GMT: > Date: Sat, 11 Apr 87 08:08:49 +1000 > Message-Id: <12085.545090929@munnari> > From: Robert Elz <seismo!munnari!kre> > Date: Fri, 10 Apr 87 11:52:31 cst > From: ihnp4!infoswx!lan000!rfw > Message-ID: <8704101752.AA13197(a)infoswx.UUCP> > In my experience, the "timezone" variable on USG systems is always > positive -- that is, application code subtracts its value from > the current time, rather than adding it. > This indicates a real bug, though your precise wording is incorrect. > The real problem is that timezone is the opposite sign than it ought > to be, and the fix is simply to negate it (always .. not just when it > would otherwise be negative), ... > Its probably indicative of just how little used this variable is > incidentally, that this bug wasn't noticed before! If there was > ever good evidence to simply kill "timezone" then I think this is it! This is, of course, the problem, since in System V 'timezone' is n o t "little used", but is used all over the place! Date uses it when setting the date. Touch, acctcom, uusub, many SCCS programs, and others (I did a 'find' on a machine far from here) use it. If it should be +5, and it is -5, that gives a 10-hour difference, which is exactly the observed problem. (As observed, it was correct for ISO conventions, but that doesn't cut it with code that assumes the opposite.) All assignments to 'timezone' were converted to negative of what they had been, all those programs (*sigh*) were re-compiled, and everything worked again. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: Ballot 4 (functions)
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt April 17, 1987

April 17, 1987

> NO int strftime(char*, int, char*, struct tm*) > NO int strfastime(char*, int, char*, struct tm*) > NO time_t mktime(struct tm*) > >strftime, strfastime, and mktime should not be standardized due to lack of >existing art. As I stated in by response to Bob, the instead of strftime() and mktime(), we could use nl_ascxtime() and gmtime2() which are in current X/OPEN systems. (Gmtime2() is a static routine and does not account for local time but but is still "existing" art. I have been tempted to post it, but I reverse engineered it directly from the AT&T gmtime() code.) Ron Tolley

1 0

Colorado time zone
by seismo!nbires!vianet!devine April 17, 1987

April 17, 1987

Yesterday the Colorado House State Affairs Committee voted 7-2 on two resolutions: to move Colorado into the Central zone and to place Colorado in year-round daylight saving time. I believe it is now up to the US Dept of Transportation to decide the result. I don't know if the Governor or state senate must do anything to the resolution. Bob Devine

1 0

Ballot 4 (functions)
by seismo!nbires!vianet!devine April 17, 1987

April 17, 1987

I can't recall if we ever resolved what functions should be in Posix. So, say "yes" or "no" to each of the following functions. Give a rationale (if you want). Add more functions if you believe they are needed. time_t time(time_t*) char* ctime(time_t*) struct tm* localtime(time_t*) struct tm* gmtime(time_t*) char* asctime(struct tm*) void tzset() int dysize(int) int strftime(char*, int, char*, struct tm*) int strfastime(char*, int, char*, struct tm*) time_t mktime(struct tm*) Bob Devine

1 0

Re: good news; missing person
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt April 14, 1987

April 14, 1987

>> ... there's "always" (supposed to be) a TZ environment >> variable in System V systems. > >That's what I thought, too. But because people were not setting the >correct time before coming up multi-user, on a System V Rev 2 V 2.0, >I put the little rc (bcheckrc?) that sets the date as the last thing >before a single-user shell, as well as the first thing after. Now I >get calls that the time is not set properly by this ... I haven't yet >investigated this properly, but it seems that the TZ is lacking here >somewhere. The correct place to set TZ is in init. I have toyed with the idea of adding a new type of line to inittab which can be used to set TZ in init so that all of init's children can know about TZ. Note however that this will never completely cure the problem, since an application may use some of the flavors of exec() which are designed to drop all environment information. Login uses such a flavor of exec() (at least currently on the system that I am using.) Still, we should be able insure that TZ is defined everywhere in the underlying platform/system on which user applications run. Ron Tolley

1 0

ballot 3 -- results
by seismo!nbires!vianet!devine April 14, 1987

April 14, 1987

Here are the opinions I received in reply to the 3rd TZ ballot. 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. b. Extend tm structure to contain local timezone offset from UT c. Extend tm structure to contain local seasonal time offset from UT d. Extend tm structure to contain timezone name e. Extend tm structure to contain a pointer to the timezone name f. Drop tm_isdst from the structure. Related questions: 1. If the structure is changed, should it be renamed? 2. What does an invalid structure contain? Can there be invalid struct tm's? 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? 5. How is the structure to be used by the mktime() function. -Bob Devine----------- c, e. Extend tm structure to contain local seasonal time offset from UT, and a pointer to the timezone name. So, struct tm (not renamed) would have two added fields the names of which should be whatever Robert Elz called them to avoid yet-another names. The "local seasonal time offset from UT" is the combination of the base timezone offset from UT and the seasonal offset used locally (aka DST). Combination is calculated according to ISO rules. The "pointer to the timezone name" would be used as a nicety but is not essential. If the pointer is NULL, a tz name can be made from the offset from UT. ---------------------- -Arthur Olson--------- Any of the above is acceptable. I prefer a, as it means the least chance of breaking existing code. If any other course is taken, I'd advocate renaming the struct. > 2. What does an invalid structure contain? Can there be invalid struct tm's? > 3. If the timezone name is included by a char pointer, how does one > make a "permanent" copy of the structure? Need not be defined in the standard. > 4. If the timezone name is included, must there be a standard for timezone > names so that a different process can make sense out of a passed structure? No. If there's a need of this sort, the need should be met with functions provided by the standard. > 5. How is the structure to be used by the mktime() function. I'd advocate that it not be used--that the mktime function be left out of the standard for now because of lack of existing art. We just don't yet know how to do it right. ---------------------- -Mark Horton---------- I vote for b+c smashed together. That is, one field which indicates the amount of time (minutes, seconds, whatever) that the time represented in the struct varies from UT. In effect it's timezone plus the appropriate number of minutes from the daylight flag. I don't care if the DST flag/minutes is also included, but I don't see the need for it. Having b and c both there would be adequate, just slightly less convenient because you'd always have to add them together. I see no need for the name of the time zone, nor for tm_isdst. ---------------------- -sfmag!jgs------------ I vote for: a. As it is defined in the SVID. ---------------------- -Ron Tolley----------- > a. As it is defined in the SVID with no added members. No. This is insufficient to handle all _known_ (Gregorian) time/date values. > b. Extend tm structure to contain local timezone offset from UT No. I assume that this is equivalent to the daylight external variable which DOES NOT change over the period of time. This is far less useful than the value which DOES change with the seasons or with DST. (If my interpretation of "seasonal" to distinguish 'b' and 'c' is incorrect, please give the one that tells about the value in the tm structure. > c. Extend tm structure to contain local seasonal time offset from UT Yes. This will allow the tm structure to contain all of the information that is known about a given time value. By adding/subtracting this value from the time_t equivalent of the tm value, one is GUARANTEED of getting UT. Date(1) MUST make use of this value. Other code should. > d. Extend tm structure to contain timezone name No. > e. Extend tm structure to contain a pointer to the timezone name Yes. Actually adding 'd' or 'e' is more important that which is added. > f. Drop tm_isdst from the structure. Retain only for backwards compatibility. > Related questions: > 1. If the structure is changed, should it be renamed? Please retain the name. There will be a period when the change is made, just as the period we are now in with DST. However this will pass relatively quickly, leaving us with a simple but improved interface. > 2. What does an invalid structure contain? Can there be invalid struct tm's? > 3. If the timezone name is included by a char pointer, how does one > make a "permanent" copy of the structure? The user should be responsible to allocate space for the string with the same lifetime as the space allocated for the tm structure. > 4. If the timezone name is included, must there be a standard for timezone > names so that a different process can make sense out of a passed structure? A null terminated string. This is intended to for human consumption. > 5. How is the structure to be used by the mktime() function. The year, month, day, hour, minute, second, and offset from UT are used to determine the value of time_t to be returned. Then the values of weekday, yearday, isdst, and (potentially) the timezone name are computed. This provides for simple, fast code. For those who wish to compute such things as weekday, there are methods which use two calls to mktime() which can be used. This is however the exception rather than the rule. ---------------------- -dreamit!jjw---------- 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. Yes b. Extend tm structure to contain local timezone offset from UT Yes c. Extend tm structure to contain local seasonal time offset from UT Yes d. Extend tm structure to contain timezone name Make it an array of applicablre names Yes e. Extend tm structure to contain a pointer to the timezone name NO! f. Drop tm_isdst from the structure. This should be an index into an array of timezone name pointers, Related questions: 1. If the structure is changed, should it be renamed? No, since this structure is built and returned internally to library functions existing programs will not normally be affected if the new fields are just added at the end. 2. What does an invalid structure contain? Can there be invalid struct tm's? No opinion. 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? If I understand the question -- the timezone name will either need to be copied separately or will need to remain during additional calls to e.g. localtime. If we retain the tzname array we should be able to guarantee that the name remains in place as long as the timezone is not changed. 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? I think timezone names are locally standardized to the point that there is no reason to standardize this. ---------------------- -Joe Yao-------------- I'm tempted by conservatism to choose a. However, I'll choose b. and c. both, simply because they really should be packaged there (and not as separate variables, as in #1). Also e., I guess. ----------------------

1 0

Re: good news; missing person
by seismo!hadron!jsdy April 13, 1987

April 13, 1987

> ... there's "always" (supposed to be) a TZ environment > variable in System V systems. That's what I thought, too. But because people were not setting the correct time before coming up multi-user, on a System V Rev 2 V 2.0, I put the little rc (bcheckrc?) that sets the date as the last thing before a single-user shell, as well as the first thing after. Now I get calls that the time is not set properly by this ... I haven't yet investigated this properly, but it seems that the TZ is lacking here somewhere. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: extending the time range
by seismo!cbpavo.MIS.OH.ATT.COM!mark April 13, 1987

April 13, 1987

I don't see 64 bits as a viable alternative; there just aren't any compilers out there that support a 64 bit integer, certainly we can't depend on it, and too much code likes to carry around a single quantity. The more I think about it, the more I think that if I am going to build a general library to handle dates and times, I'm not going to use a time_t as my canonical type, even extended to 64 bits. I need things like variable precision (e.g. my birthday should be clearly precise to the day, not the second, but some measurements have subsecond precision) and the ability to handle notions like "before". I don't see any reasonable way to implement it except using a character string as the canonical format - a char string in ISO format can do it pretty cleanly. Mark

1 0

good news; missing person
by ado April 12, 1987

April 12, 1987

The new time zone stuff and System V time zone stuff behave differently if there's no TZ environment variable. The good news is that this difference is irrelevant, since there's "always" (supposed to be) a TZ environment variable in System V systems. This also means, of course, that other time zone handling schemes are free to do whatever they want if TZ is absent. (Now if I can just remember this until the next time it comes up. . .) Missing person department: mail can no longer be sent to greg(a)nosc.arpa, who's been on the list until now. If anyone has a fully-domainized address for greg, let me know. --ado

1 0

tzsetwall() vs. doing explicit things
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Quick question: doesn't a new question warrant a new Subject: line? We've been going quite a while on these two ... I think that one should use a function specially provided (tzsetwall()) to set the time to "wall clock" time. This could unsetenv("TZ"), or read the "localtime" file for appropriate values of "TZ", or whatever. I like the latter approach, myself ... probably requires unsetenv() and setenv() to do right, though. The point is that we should hide as much of the messy detail as possible inside the time library/module. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: extending the time range
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Agreed, there should probably be a new data type (although mark's suggestion tickles my fancy, as a short-range hack). But 64 bits is still limiting. I like an earlier suggestion to use a text- string or a coded decimal string date. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

TZ changes
by seismo!sun!gorodish!guy April 10, 1987

April 10, 1987

In my experience, the "timezone" variable on USG systems is always positive -- that is, application code subtracts its value from the current time, rather than adding it. I have supplied a diff for localtime.c so that if USG_COMPAT is defined, the value of the global "timezone" variable is forced positive. This is based on observations of Plexus System 3, Xenix System 3, and Xenix System 5. I don't know how USG would treat negative offsets from GMT. Observations presumably not made in Europe. You are correct in that the sign of the "timezone" variable should be positive for time zones such as those in the Western Hemisphere; however, it is not correct to force the offset to be positive, as there are places where the offset simply *isn't* positive (using the UNIX sign conventions). The correct fix is 182c185 < timezone = s.ttis[0].tt_gmtoff; --- > timezone = -s.ttis[0].tt_gmtoff; 197c200 < timezone = ttisp->tt_gmtoff; --- > timezone = -ttisp->tt_gmtoff; or something like that.

1 0

None
by Robert Elz April 10, 1987

April 10, 1987

Date: Fri, 10 Apr 87 11:52:31 cst From: ihnp4!infoswx!lan000!rfw Message-ID: <8704101752.AA13197(a)infoswx.UUCP> In my experience, the "timezone" variable on USG systems is always positive -- that is, application code subtracts its value from the current time, rather than adding it. This indicates a real bug, though your precise wording is incorrect. The real problem is that timezone is the opposite sign than it ought to be, and the fix is simply to negate it (always .. not just when it would otherwise be negative), in zones east of Greenwich, "timezone" should in fact be negative (and the application still subtracts its value from the current time). Its probably indicative of just how little used this variable is incidentally, that this bug wasn't noticed before! If there was ever good evidence to simply kill "timezone" then I think this is it! I would also be interested in exactly what application that you have that uses this variable. Does it use it correctly? Simply subtracting it from a time isn't correct, as that won't work in daylight saving times. About all I can think of is that you look at tm_isdst and if that's set compensate by 1 hour (assuming that it is, always, one hour). I don't think the other fixes are appropriate at the minute, but this one will get into a patch posted to mod.sources. Robert Elz

1 0

Re: Reason for DST change in US
by seismo!nbires!vianet!devine April 9, 1987

April 9, 1987

>From uucp Wed Apr 8 17:00 EST 1987 >From hadron!jsdy Wed Apr 8 07:37:44 1987 remote from nbires Received: from hadron.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA00984; Wed, 8 Apr 87 10:21:59 EDT Received: by hadron.UUCP (4.12/4.7) id AA02725; Wed, 8 Apr 87 10:17:34 est Date: Wed, 8 Apr 87 10:17:34 est From: hadron!jsdy (Joseph S. D. Yao) Message-Id: <8704081517.AA02725(a)hadron.UUCP> To: nbires!vianet!devine Subject: Re: Reason for DST change in US Cc: elsie!tz Joe Yao writes: > (*sigh*) That may have been a contribution (nopunintended) to DST > being finally implemented. I know the Farmers' lobby was agin' it. > However, Ben Franklin thought up the idea during one of his ... > ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. > That was a few years before Clorox and Charcoal Briquettes. > > I do notice, however, that your article did not claim that it was > solely done at the behest of Halstead, nor solely for his benefit. > I seem to vaguely recall some other considerations. And that was > definitely not the consideration for its adoption during the War(s), > which was probably what inspired Halstead et al. later on. You misunderstand. I said that the Halstead proposal was just for moving the start of US's DST from the last Sunday in April to the first. I did not write that Halstead was responsible for the invention of the DST idea. His lobbying of Congress occurred about 4 years ago. Here's a thumbnail sketch of how DST came to be: Benjamin Franklin's suggestion for DST was during his tenure as the US ambassador to France (not some junket). His suggestion was ignored. Probably because of the confusion that would have been added to the non-standard timezones then used. However, the true inspiration for DST might have come from a more modern source. An Englishman, William Willet, published a pamphlet in 1907 that called for a seasonal variation in much the same way that Franklin had proposed over a hundred years before him. The first real use of DST came about because of the demands of war. Germany used it during WW I to save electricity. The UK soon followed and many countries did likewise. Most called it "summer time" or "war time". After WW I was over, DST was not observed uniformly across the US because Congress stopped the national observance but many localities kept it anyway. Bob Devine

1 0

Re: Reason for DST change in US
by seismo!hadron!jsdy April 8, 1987

April 8, 1987

> Cost for this recreation windfall was about $50,000 in lobbying costs. (*sigh*) That may have been a contribution (nopunintended) to DST being finally implemented. I know the Farmers' lobby was agin' it. However, Ben Franklin thought up the idea during one of his ... ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. That was a few years before Clorox and Charcoal Briquettes. I do notice, however, that your article did not claim that it was solely done at the behest of Halstead, nor solely for his benefit. I seem to vaguely recall some other considerations. And that was definitely not the consideration for its adoption during the War(s), which was probably what inspired Halstead et al. later on. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Reason for DST change in US
by seismo!nbires!vianet!devine April 7, 1987

April 7, 1987

The Associated Press ran a short story this past week on how the change in daylight saving time came to be. The following is not a verbatim transcription but the parts that caught my eye. J. Phillip Halstead was the manager of public affairs at Chlorox Co. and was trying to increase the sales of its Kingsford brand of charcoal briquettes. He found that sales would go up 5-15% for each month that had an extra hour of daylight. He said "More light equaled more barbecues and more charcoal briquettes." Halstead now has a consulting business and estimates that the one hour shift is worth about $4 billion in additional sales for outside- based recreation. Another figure: there will be 4 million additional golf games. Cost for this recreation windfall was about $50,000 in lobbying costs. Bob Devine

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by Steve Summit April 6, 1987

April 6, 1987

>> I cannot be sure that my customers will install the necessary >> timezone support files. > Neither can you be sure that they will install /etc/passwd. You don't > handle that, why handle this? /etc/passwd is standard on the systems I'm selling to; /etc/zoneinfo isn't (yet). A customer doesn't have to install /etc/passwd to get my software to run; I know he already has it, or else he's got a broken system, and it's his problem, not mine. >> I insist that both timezone and DST corrections be applied, even in >> the absence of /etc/zoneinfo, which means that ctime must carry >> some DST information along in its data segment, so it can perform >> at least as well as it used to. > This is unclear to me. What I'm worried about here is systems that haven't applied any fixes. I detest "two steps forward, one step back" improvements, so I'm trying to arrange that a ctime that I link into my code behave 100% backwards-compatibly when shipped to a site that depends on using the old ctime. By "backwards-compatibly," I mean that any new ctime, when operating in an environment without /etc/zoneinfo, must generate the same results as (i.e. localtime must be functionally identical to) the "old" versions of ctime. If not, there will be periods of time (such as the three-week period when lazy and/or sensible systems simply set their clock ahead by an hour) during which the new version of ctime will generate a different local time value than the rest of the utilities on the system (date, ls, anything linked with the old ctime) when presented with the same kernel timestamp. >> The next question is, should any DST information hard-compiled >> into ctime be fixed to reflect recent changes? The surprising >> answer is "no." > That means that your worst case is off by an hour. (Ignoring double > DST.) The same as 4.3's. What am I missing? No. It's off by 0 hours, at all times of any past or present year, when shipped to a system that applies no fixes. (Actually, there is a worse worst case, that of the site that applies the fixes in Article 13, to arrive at a temporarily fixed but still non table-driven ctime. I can't arrange for things to work correctly in this case without breaking things in the other two cases, and I consider the other two cases -- the no fix case and the Arthur Olsen case -- more likely.) Actually, no one else here at Tektronix is at all concerned about this issue, and the witching hour has come and gone, so it's probably not worth our thrashing this out. I thought my arguments were fairly convincing, and I tried to sweeten the pot by offering working code, but I admit that these are pretty fine points I'm considering, and since nobody else seems to be interested, I think I'll drop the whole thing and go off and find other damsels to rescue :-). Steve Summit

2 1

Ballot 3 -- struct tm
by seismo!nbires!vianet!devine April 4, 1987

April 4, 1987

On this ballot feel free to mix'n'match your choices. 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. b. Extend tm structure to contain local timezone offset from UT c. Extend tm structure to contain local seasonal time offset from UT d. Extend tm structure to contain timezone name e. Extend tm structure to contain a pointer to the timezone name f. Drop tm_isdst from the structure. Related questions: 1. If the structure is changed, should it be renamed? 2. What does an invalid structure contain? Can there be invalid struct tm's? 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? 5. How is the structure to be used by the mktime() function.

1 0