Re: OT: Re: Less is more

On Thu, 6 May 2004 19:26, Paul Smith wrote:
> Does linux/unix's OS 'get time' API report leap seconds or not? Does it
> need updating with a table of leap seconds periodically? Can you get the
> time as h:m:s, or do you have to get it as an epoch value and convert it?
> Is that epoch value affected by leap seconds.

The standard C library function mktime() has been specified in terms of proper 
UTC time calculus (thus incorporating the need for a leap second table in the 
implementation) since at least 1990 (ISO 9899:1990).  But this isn't a "get 
time" call -- it's a UTC date manipulation function.

The status of time_t (seconds since the epoch), returned by the time() and 
gettimeofday() functions, is murky. The seconds appear to be solar seconds, 
not atomic seconds, although the epoch is 1970-01-01T00:00:00Z, which is a 
UTC date, and thus ought to be tied to atomic seconds. While searching for 
information on the matter, I found the following rather interesting snippet 
on a leap-second-specific mailing list.

http://www.mail-archive.com/leapsecs%40rom.usno.navy.mil/msg00109.html

My brain hurts from trying to figure out where the status quo lies, but my 
best estimate is that time_t counts in 86400-second days, with zero 
corresponding to the epoch date mentioned above. Thus it is neither properly 
UTC nor UT1 (it has a UTC epoch and UT1 seconds). The functions which convert 
time_t values to "struct tm" (as used by mktime) know this, of course, and a 
consequence of this is that no time_t conversion ever results in a leap 
second date.

With a little experimentation, I find that I am unable to make my allegedly 
POSIX and/or ISO compliant C implementations (GNU/Linux or Solaris) produce a 
leap-second date (specifically, 1998-12-31T23:59:60Z) using mktime(). If 
anyone can reproduce a result where mktime() considers the 61st second of a 
minute normalised, then please send me a copy of the code and tell me what OS 
or C library was used.

Realistically, we may have to say that timestamps may be derived from either a 
UTC or UT1 time-base (or some forsaken hybrid of the two, which seems to be 
the status quo), noting that this means implementations should cope with a 
value of "60" in the seconds position (and deal with it properly, or by 
conversion to an adjacent non-leap second, as convenient). Times can't be 
relied on to be accurate to more than a couple of seconds because of this, 
but in actual practice many mail clients have clocks with far greater loss of 
synchronisation than that, so the date shouldn't be considered "reliable" in 
any sense at all.

My sense of engineering purity is being slowly beaten to death by reality 
again.