Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!gatech!purdue!umd5!cvl!elsie!ado
From: ado@elsie.UUCP (Arthur David Olson)
Newsgroups: comp.bugs.4bsd
Subject: Re: ctime(3) and leap seconds :-)
Summary: ANSI C vs. leap seconds
Keywords: ctime, leap second, epoch
Message-ID: <7562@elsie.UUCP>
Date: 8 Jan 88 18:15:25 GMT
References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <6977@brl-smoke.ARPA>
Organization: NIH-LEC, Bethesda, MD
Lines: 37

> > The C library time routines are not PERMITTED to know about leap
> > seconds, according to the current draft proposed ANSI C standard.
> Oops, excuse me -- it is IEEE Std 1003.1 (POSIX) Draft 12 that
> says this; ANSI C does not dictate what the system time
> representation is.

There is one conflict between leap seconds and draft proposed ANSI C.
When the leap seconds occur, the time is "supposed" to be counted thus:
		...
		23:59:58
		23:59:59
		23:59:60
		00:00:00
		00:00:01
		00:00:02
		...
which means that one or two times a year (typically) the "tm_sec"
field of a "struct_tm" should have the value 60.  The November '87
draft, though, specifies that tm_sec is confined to the range 0..59.

Of course if you're willing to fudge and simply repeat the
		23:59:59
or the
		00:00:00
there's no problem.  (For those using the mod.sources table-based time
functions, lines such as

	# Rule NAME FROM TO   TYPE IN  ON AT        SAVE     LETTER/S
	Rule   US   1988 only -    Jan 1  00:00:00 -00:00:01 S

do the trick by repeating the 23:59:59; change the "AT" filed to "00:00:01"
to repeat the first second of the new year rather than the last of the old.)
-- 
Bugs is a trademark of Warner Brothers/Volkswagen.
Time is a trademark of Time-Life Incorporated.
-- 
ado@vax2.nlm.nih.gov		ADO, VAX, and NIH are Ampex and DEC trademarks