[LEAPSECS] leap smear

[Joe Gwinn]

At 7:04 PM +0000 9/18/11, Michael Deckers wrote:

>    On 2011-09-18 17:14, Joe Gwinn wrote:

>

>>  The handling of leap seconds is not defined in POSIX, which does not

>>  apply leap seconds. ................................................

>

>    POSIX requires that the time_t value returned by time() had

>    to increase by 3 while UTC increased from 2008-12-31T23:59:58 to

>    2009-01-01T00:00:01. This interval included a leap second and

>    was 4 s long, so POSIX arguably must "apply" leap seconds.


Not so.  POSIX speaks of leap seconds only to say that leap seconds 
are ignored.  The fact that the operating system kernel and/or the 
GPS receiver have some way to handle leap seconds is outside of the 
scope of POSIX.



>    Moreover,

>    different flavors of UNIX press these 4 s into 3 units of

>    time_t (and timeval or timespec) in different ways,


True enough.



>as a monotone

>    and continuous function of TAI.


Yes.  As defined, POSIX time is in effect a form of TAI, differing by 
a constant offset, but this is nowhere stated.



>>  ................... The result is that the handling of leap seconds

>>  depends on some combination of the GPS timeserver providing UTC to the

>>  computer, [and] the operating-system kernel implementation.

>

>    Yes. My point is that POSIX fails to give guidelines on how to

>    make these time_t (and timeval or timespec) values precisely

>    understandable to applications, and comparable across systems.


The POSIX committee decided not to give any such guidelines, because 
it proved far too contentious, and POSIX cares about computers and 
operating systems, and not nearly as much about time issues.



>    Currently, only struct tm values can be used for that purpose.

>    No wonder some people want to eliminate future leap seconds --

>    this would also remove all those problems.


I doubt that the push to drop leap seconds has anything to do with 
POSIX - there are far larger forces at play.

Joe Gwinn