Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!gatech!hao!ames!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: <38377@sun.uucp>
Date: 10 Jan 88 00:03:32 GMT
References: <604@PT.CS.CMU.EDU> <6976@brl-smoke.ARPA> <20532@amdahl.amdahl.com>
Sender: news@sun.uucp
Lines: 49

>     Epoch:
> 	The Epoch refers to the time at 0 hours, 0 minutes 0 seconds,
>	Coordinated Universal Time on January 1, 1970.  The value "seconds
>	since the Epoch" refers to the difference in seconds between the
>	referenced time and the Epoch, not counting leap seconds.
> 
> The reason why this was put into the standard was to avoid having to
> put things like this fix into your code.  (most systems do not do this,
> so the standard reflects this)

It is worth nothing at this point that most systems also do not provide
POSIX-conformant time, and are unlikely ever to do so; instead of providing
time in "seconds since the Epoch", they provide the number of seconds since 0
hours, 0 minutes, 0 seconds, SWT (Somebody's Watch Time) on January 1, 1970.

It is also worth noting that if a system decided to provide 100%
POSIX-conformant time, it would have to ensure that the clock did not advance
during a leap second.

Think of it this way: a machine's clock provides coordinates along a time axis,
starting with 0 at the Epoch and progressing nicely at the rate of one tick per
second.  A "time", either local or Coordinated Universal, can be thought of as
a label applied to a point on this axis.  For instance, the label
"00:00:01 1/1/70" is applied to the point one second from the Epoch.

The coordinates along this time axis correspond most naturally to "time_t"s.
"time"s, i.e., the labels, correspond most naturally to "struct tm"s.  What
most systems do not do is throw leap seconds into the conversion between
"time_t" and "struct tm", i.e. into "localtime" and "gmtime".

If an implementation wishes to take leap seconds into account, it can either
treat "time_t"s as labels (i.e., hold the system clock back on leap seconds) or
as coordinates (i.e., throw the leap second conversion into "localtime" and
"gmtime", perhaps by doing it the "correct" way and adding a 61st second to
some minutes).  Most implementations do not do *either* one; the current
wording in the standard technically requires implementations to do *something*,
namely stop the clock during leap seconds - it does not permit existing
implementations to conform down to the last dotted "i" and crossed "t".

I would say that what *really* needs to be done is to recognize that few, if
any implementations can possibly conform in the strictest sense, as few of them
e.g. listen to WWV to set their clocks (and, I suspect, few customers are
willing to pay the extra cost of having their system listen to WWV just so that
they can be guaranteed not to have their clocks off even by one second), and to
indicate that "seconds since the Epoch" merely indicates some reasonable effort
to come *close* to seconds since the Epoch.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com