[time-nuts] Leap seconds and POSIX

[Joe Gwinn]

Warner,

At 6:35 PM +0000 1/1/09, time-nuts-request at febo.com wrote:
>
>Message: 6
>Date: Thu, 01 Jan 2009 11:28:03 -0700 (MST)
>From: "M. Warner Losh" <imp at bsdimp.com>
>Subject: Re: [time-nuts] Leap seconds and POSIX
>To: time-nuts at febo.com, joegwinn at comcast.net
>Message-ID: <20090101.112803.179959520.imp at bsdimp.com>
>Content-Type: Text/Plain; charset=us-ascii
>
>In message: <p06240822c582a02c4f73@[192.168.1.212]>
>             Joe Gwinn <joegwinn at comcast.net> writes:
>: 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.)
>
>If POSIX had allowed for the system time to be TAI, and have the
>offset applied for the display of times, then there would be no
>ambiguity.  However, this is not allowed because one must be able to
>do math on time_t such that time_t % 86400 is midnight.

Defining a formal equivalence of some kind to TAI was proposed, but 
was not accepted, largely because they had were not linked at the 
beginning, and there would be many details that were not quite right.


>: So, at least in theory, POSIX time is a form of TAI, having a
>: constant offset from TAI.
>
>Except that the offset isn't constant :(.

True, as discussed next.


>: 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.
>
>When the INS bit is set in the NTP packets, NTP tells the kernel about
>it, which replays the last second of the day to keep in step.  I'm not
>sure this is a transient error or not, since ntp_gettime can be used
>to determine that this is the leap second for applications that care.
>However, it does introduce a glitch in the data produced by system
>interfaces that don't have leap second indicators...

Platforms vary because NTP is at the mercy of the kernel developers. 
 From the standpoint of the average user, there is a transient error. 
Not that many average users will notice, so long as nothing crashes 
or hangs.

In systems where the transient error and possibility of a crash or 
hang cannot be tolerated, one common dodge is to lie to NTP by 
configuring the GPS receiver and NTP timeserver to emit GPS System 
Time, and live with the fact that the local computer clocks are ~14+ 
seconds off of UTC.  Purpose-built user displays are programmed to 
compute and use the correct time.

Joe