- tz - lists.iana.org

Leap seconds
by Ronald G. Tolley June 6, 1988

June 6, 1988

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

1 0

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

June 2, 1988

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

1 0

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

June 2, 1988

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

1 0

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

June 1, 1988

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

1 0

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

June 1, 1988

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

1 0

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

May 31, 1988

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

2 2

Re: tz package
by ado May 30, 1988

May 30, 1988

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

1 0

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

May 30, 1988

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

2 1

More converts?
by ado May 2, 1988

May 2, 1988

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

1 0

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

April 26, 1988

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

1 0