- tz - lists.iana.org

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

June 1, 1988

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

1 0

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

June 1, 1988

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

1 0

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

May 31, 1988

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

2 2

Re: tz package
by ado May 30, 1988

May 30, 1988

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

1 0

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

May 30, 1988

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

2 1

More converts?
by ado May 2, 1988

May 2, 1988

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

1 0

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

April 26, 1988

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

1 0

Interested in time.
by DF Hoerl April 24, 1988

April 24, 1988

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

1 0

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

April 20, 1988

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

1 0

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

April 8, 1988

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

1 0