[time-nuts] Leap seconds and POSIX

Joe Gwinn joegwinn at comcast.net
Fri Jan 2 17:32:51 UTC 2009


Magnus,

At 12:00 PM +0000 1/2/09, time-nuts-request at febo.com wrote:
>Message: 1
>Date: Fri, 02 Jan 2009 09:45:23 +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>
>
>>>  : 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.
>
>For many of the places where POSIX is being used these days, this kind
>of reasoning is not helpful to say the least.

But is it correct?  Remember, most people understand little and care 
less about time, except insomuch as it affects something they do care 
about.

There has been a flurry of reports of leap-second induced failures on 
"comp.protocols.time.ntp".  This is precisely why some systems must 
avoid UTC.


>For instance, it is being used in many systems where high availability
>as well as propper logging is concerned. In addition to that, UTC may
>very well be the time-scale of choice, thought TAI could be used if
>properly identified as such.

In the financial and legal worlds, UTC is the standard choice, and 
many GPS receivers are purchased for legally-tracable timestamping.


>If POSIX standard time were TAI and NTP was steering it as TAI in all
>the boxes, then things would work. We would need to convert into UTC and
>then into local time-zone as part of presentation.

I recall Dave Mills discussing this as a possibility, but being 
unable to achieve it, for reasons I don't recall.


>If POSIX standard time were UTC and NTP was steering it as UTC in all
>the boxes, then things would work. We would need to convert into local
>time-zone as part of presentation.
>
>Oh, time-zone is a presentation issue and not a "box" issue.

There is also a move afoot to cease to have leap seconds , instead 
correcting UTC manually every ten or more years.   If this were done, 
then UTC would become uniform and smooth, and the TAI possibility 
would be eclipsed. The first possible ITU vote on this would be at 
their 2010 meeting, the ITU isn't likely to approve something that 
large the first time, and the DoD proposes that the change not be 
effective before 2018 at the earliest.   Ref: "Discontinuance of Leap 
Second Adjustments", John G. Grimes, Assistant [US] Secretary of 
Defense, Networks and Information Integration, 3 September 2008, 3 
pages.


Joe




More information about the Time-nuts_lists.febo.com mailing list