- tz - lists.iana.org

oops--tzcode94g.tar.gz
by ado May 5, 1994

May 5, 1994

The file tzcode94f.tar.gz was missing "optind.c" and a reference to it in the Makefile; tzcode94g.tar.gz remedies the problem. --ado

1 0

tzcode94f.tar.gz
by ado May 5, 1994

May 5, 1994

The file tzcode94f.tar.gz is now available for anonymous ftp from the "~ftp/pub" directory on elsie.nci.nih.gov (128.231.16.1). It includes changes to avoid overflow in difftime, as well as changes to cope with the 52/53 challenge in strftime. --ado

1 0

difftime overflows when it shouldn't
by eggert＠twinsun.com May 3, 1994

May 3, 1994

Let's take the common case where time_t ranges from -2147483648 through 2147483647, and `double' is IEEE 754 double precision. Then, under tz-1994e, the program #include <time.h> #include <stdio.h> #define MAX_TIME 2147483647 #define MIN_TIME (-1 - MAX_TIME) int main() { printf("difftime(%ld, %ld) = %.17g\n", (long) MAX_TIME, (long) MIN_TIME, difftime(MAX_TIME, MIN_TIME)); return 0; } outputs difftime(2147483647, -2147483648) = -1 There's no reason for difftime to report the wrong answer, since the result is exactly representable. Here is a patch. =================================================================== RCS file: difftime.c,v retrieving revision 1994.5 retrieving revision 1994.5.1.1 diff -c -r1994.5 -r1994.5.1.1 *** difftime.c 1992/04/23 17:34:30 1994.5 --- difftime.c 1994/05/03 04:30:43 1994.5.1.1 *************** *** 13,17 **** const time_t time1; const time_t time0; { ! return time1 - time0; } --- 13,28 ---- const time_t time1; const time_t time0; { ! if (sizeof(time_t) < sizeof(double)) ! return (double) time1 - (double) time0; ! else { ! time_t delta = time1 - time0; ! if ((~time1 & time0 & delta) < 0) { ! time_t hibit; ! for (hibit = 1; (hibit <<= 1) > 0; ) ! ; ! return delta - 2.0 * hibit; ! } else ! return delta; ! } }

1 0

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