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.
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
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