[time-nuts] Leap seconds and POSIX

[Joe Gwinn]

Magnus,

At 8:39 AM +0000 1/2/09, time-nuts-request at febo.com wrote:
>
>Message: 9
>Date: Fri, 02 Jan 2009 09:35:59 +0100
>From: Magnus Danielson <magnus at rubidium.dyndns.org>
>Subject: Re: [time-nuts] Leap seconds and POSIX
>To: Discussion of precise time and frequency measurement
>	<time-nuts at febo.com>
>Message-ID: <495DD1EF.7030904 at rubidium.dyndns.org>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Joe Gwinn skrev:
>>  Having worked in the POSIX committee for many years, I can shed some
>>  light on how POSIX handles leap seconds:
>>
>>  In short, POSIX adamantly ignores leap seconds.  All days in POSIX
>>  have the same length, 86,400 seconds.
>>
>>  This omission is not by accident, instead having been violently
>>  debated at length, and voted upon.
>>
>>  The rationale is that one cannot assume that all POSIX systems have
>>  access to leap second information, or even the correct time, and yet
>>  must work in a reasonable manner.  In particular, file modification
>>  timestamps must allow one to determine causal order (to within one
>>  second in the old days) by comparison of timestamps.  (Yes, people do
>>  realize that timestamps are not the perfect way to establish causal
>>  order, but are nonetheless widely used in non-critical applications.
>>  Critical applications instead use some kind of atomic sequence-number
>>  scheme.)
>>
>>  So, at least in theory, POSIX time is a form of TAI, having a
>>  constant offset from TAI.
>>
>>  In practice, in platforms that have access to GPS, NTP is used to
>>  servo the local computer clock into alignment with UTC (or GPS System
>>  Time (UTC without the accumulated leaps) in systems that abhor time
>>  steps), and there is a transient error just after a leap second while
>>  NTP recovers.
>
>The problem with the POSIX time is that it can't be UTC but fails to
>identify itself as either TAI, UT1 or even UT2. If it clearly identified
>itself as being one of those, or similar (say GPS time) then things
>would be much improved. However, it is being interprented as being UTC
>which it fails to handle. I think the UT1 and UT2 alternatives would be
>best suited.
>
>I don't mind that the default time in POSIX remains there, but I don't
>think it helps that there is no way to get proper UTC time by a
>standardized interface.

Actually, this isn't quite true, as POSIX provides a standard (POSIX) 
Re: [time-nuts] Leap seconds and POSIX way to define non-standard (to 
POSIX) clocks.  So, if a vendor felt the need, they could define and 
provide a real TAI clock for instance.

That said, I don't know of anybody having done this, but I have not 
looked either.


>Attempting to say "It's UTC, except on leap seconds" is not a workable
>solution if you are locked up and a leap-second do occur. It only works
>if you are not locked up and free runs on whatever you have. However,
>more and more systems actually needs to be locked up and they may also
>need to have propper UTC. We see needs to have logs in UTC and
>coordinated over many countries and time-zones.
>
>This is not only a matter of how we deal with leap-seconds, but how we
>deal with time. We need to be able to actually deal with propper UTC
>regardless, and we need to know it is UTC "traceable" (in a wider sense
>most of the time, but occasionally in propper sense) or not.

There are something like 20 named timescales at the international 
level, most being paper clocks to be sure, but each has a purpose and 
a set of properties, and serves some need.  By implication, there is 
no single One True Clock.

A better way to approach this is to see that POSIX time is yet 
another timescale, with a purpose and a set of properties.


>I find the current situation unsatisfactory.

It is what it is.  Computer platform vendors traditionally cared 
little about time, and about realtime.  The rise of interest in audio 
and video media caused the vendors to become interested in realtime 
issues and performance, and thus indirectly about time.  But only to 
the degree needed to support handling of such media.


Joe