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
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
