- tz - lists.iana.org

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