Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!rutgers!mcnc!rti!trt
From: trt@rti.UUCP (Thomas Truscott)
Newsgroups: comp.bugs.4bsd
Subject: Re: ctime(3) and leap seconds :-)
Summary: let's do leap seconds correctly
Keywords: ctime, leap second, epoch
Message-ID: <1964@rti.UUCP>
Date: 11 Jan 88 19:28:18 GMT
References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <20532@amdahl.amdahl.com> <175@wundt.psy.vu.nl>
Organization: Research Triangle Institute, RTP, NC
Lines: 36

> I really couldn't care much about 14 secs in 18 plus years.

Yes, 14 secs one way or another is no big deal.
So you won't care if someone fixes the leap-second bug in ctime, right?

AS WE ALL KNOW
UNIX (and other systems) internally maintains the seconds that have 
elapsed since <EPOCH>.  If at a given instant the elapsed time is 't',
then one second later the elapsed time will be 't+1'.
This is unaffected by time zones, daylight savings time,
leap days, leap seconds, or any other artifacts of man.
This is the fundamental representation of time in UNIX (and other systems):
other representations are derivatives and should be treated as such.

AND THEREFORE
The ctime() routine, which converts "EPOCH time" such as 
    568924849
into something more understandable by man such as
    Mon Jan 11 13:40:49 1988
must take into account the artifacts such as time zones, etc.
including *leap seconds* or else ctime() will produce the wrong answer!
Similarly for the inverse routines ("getdate", "timec", any standards yet?)
that convert a user-supplied date into EPOCH time.

DO NOT ATTEMPT TO FIX THE BUG BY DOCUMENTING IT!
We might document "ignore leap seconds" but that results in
small but very real errors that someday could cause real harm.
Should we document "ignore the difference between sidereal
and solar timekeeping systems"?
There is no end to this!

I SUGGEST THAT POSIX
1. Encourage fixes for the leap-second and other problems of ctime()
    and related programs.
2. Document that application of such fixes is recommended.
	Tom Truscott