[LEAPSECS] POSIX Time (was WP7A)
joegwinn at comcast.net
Sat Oct 10 20:04:05 EDT 2009
At 12:22 AM +0100 10/11/09, Zefram wrote:
>Joe Gwinn wrote:
>>If you read the POSIX standard, you will find that the length of the day
>>is defined as exactly 86,400 seconds, no more no less.
>Not quite. To be precise, the time_t value increases by exactly 86400
>per day, *regardless of how long the day is*. A POSIX time_t value is a
>(lossy) transformation of a broken-down UTC time, *not* a linear count
While in actual use you are correct or correct enough, the actual
definition is as I stated. One must read the words as they are on
the page, without assumptions about common implementations.
> >Another common source of confusion is that the POSIX Epoch is an instant
>>defined in UTC terms,
>... and occurring at a time for which the present form of UTC is
>undefined. I don't think anyone actually attempts to apply the POSIX
>time_t definition to pre-1972 (pre-leap-seconds) UTC. De facto, Unix
>timestamps of any significant age cannot be precisely related to UTC
>(or TAI or any other precision time scale). Historical time_t values
>can at best only be interpreted as a transformation of vague UT, unusable
>for sub-second absolute timing. (Actually, you won't often see pre-1990
>timestamps that are accurate to the minute, let alone precise enough to
>distinguish between flavours of UT.)
All kinda true, but for the intended use of POSIX Time, the errors
are not significant bu the relevant users. For instance, the UTC
definition of the POSIX Epoch (originally defined in terms of GMT) is
off by about 80 microseconds (if memory serves).
> >> A user wishing to display correct UTC time during leap-second would
>>> need to querry the NTP kernel
>>A tall order for sure,
>The ntp_adjtime() interface is semi-standard for Unix systems.
>Interpreting all the variations of the interface is a bit of a task.
>In the future the OS variants in how to do this should all be hidden by
>uniform higher-level interfaces. That's the intent of my Perl module
The ntp_adjtime() interface is almost standard for sure, but how the
operating system kernel implements it is all over the map. One
method is to track the error, and when it exceeds 0.5 mS, yank the
clock in the opposite direction by 1.0 mS; this jump occurs every 100
seconds or so.
An 80 microsecond error would be swamped, which is one reason the
POSIX Committee didn't worry about the GMT-UTC delta error in the
definition of the Epoch.
Nor is there an "NTP kernel" per se. It's the operating system
kernel that implements ntp_adjtime(), and the NTP daemon (a bit of
application code) calls on adjtime to steer the local computer clock.
More information about the LEAPSECS