Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdahl!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: ctime(3) and leap seconds :-(
Keywords: ctime, leap second, epoch
Message-ID: <38643@sun.uucp>
Date: 12 Jan 88 22:16:16 GMT
References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <20532@amdahl.amdahl.com> <20697@amdahl.amdahl.com>
Sender: news@sun.uucp
Lines: 47

> If you leave it up to the vendors to fix or not fix time based on leap
> seconds, then you could be faced with synced machines on a localarea net
> converting into or out of timestamps differently.

Please define what a "timestamp" is!  Is a "timestamp" a value as returned by
"time()", or a value as returned by "time()" and subsequently convered by
"localtime()" or "gmtime()"?  The time stamps that are applied to files by UNIX
systems tend to be the former, as do the fundamental notion of time in such
systems.  I infer from your other statements, though, that you use the latter
notion of "timestamp".

The problem you cite - "struct tm" values with "tm_sec" equal to 60 - has
NOTHING WHATSOEVER to do with the former ("time_t" time stamps), only the
latter.  Therefore, to fix this problem, the definition of "seconds since the
Epoch" need not be changed; the net result will be that a system that keeps
"perfect" time (i.e., the system clock, as returned by "time()", was correctly
set to the number of seconds since the Epoch - *counting* leap seconds, i.e.
ignoring the artifacts of human-developed timekeeping systems that attempt to
correlate time values to the behavior of heavenly bodies - is incremented by
one precisely every second) will generate "struct tm" values that slowly drift
with respect to what various time standards showing time values using the
aforementioned timekeeping systems say.

The only way to fix this drift would either be to 1) change "localtime" to take
leap seconds into account or 2) change the system so that the values returned
by "time" take leap seconds into account.  In short, you CAN'T fix it without
teaching systems about leap seconds if they do not already use clocks that know
about leap seconds.

> The 14 seconds between synced machines could be a non-trivial difference.

Yes, for programs that use "struct tm" values and expect them to match up.  No,
for programs that use "time_t" values and expect them to match up.

Therefore, the wording in the definition of "Epoch" in the front of P1003.1 is
completely wrong, as it requires implementations to keep track of leap seconds
anyway (if you don't believe me, please read my previous article and Tom
Truscott's article and refute the points stated therein).

If you believe that the conversions performed by "localtime" and "gmtime"
should not take leap seconds into account (a position that is subject to debate
- I'll let Tom Truscott take the view opposed to yours on this), please *fix*
the definition of "Epoch" and change the writeups on "localtime" and "gmtime"
instead.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com