[ntp:questions] basic questions about the leapsecond

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 16 02:24:55 UTC 2008


Greg Dowd wrote:
> -----Original Message-----
> From: questions-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:questions-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf
> Of Richard B. Gilbert
> Sent: Monday, December 15, 2008 1:08 PM
> To: questions at lists.ntp.org
> Subject: Re: basic questions about the leapsecond
> 
> Greg Dowd wrote:
>> I think it is the original rfc1305 (NTPv3) language that determined
> that
>> the bits only show up on the day of the event.  While the actual
>> requirement is merely that they are set before 23:59 and cleared after
>> midnight, the supporting text is shown below.
>>
>>
>> "On the day prior to the insertion of a leap second the leap bits
>> (sys.leap) are set at the primary servers, presumably by manual means.
>> Subsequently, these bits show up at the local host and are passed to
> the
>> local-clock procedure. This causes the modulus of the time variable,
>> which is the length of the current day, to be increased or decreased
> by
>> one second as appropriate. Immediately following insertion the leap
> bits
>> are reset. Additional discussion on this issue can be found in
> Appendix
>> E."
>>
>> >From Appendix E
>> "The chronometry involved can be illustrated with the help of Figure
> 8,
>> which shows the details of seconds numbering just before, during and
>> after the last scheduled leap insertion at 23:59:59 on 31 December
> 1989.
>> Notice the NTP leap bits are set on the day prior to insertion, as
>> indicated by the <169>+<170> symbols on the figure. Since this makes
> the
>> day one second longer than usual, the NTP day rollover will not occur
>> until the end of the first occurrence of second 800. The UTC time
>> conversion routines must notice the apparent time and the leap bits
> and
>> handle the timescale conversions accordingly. Immediately after the
> leap
>> insertion both timescales resume ticking the seconds as if the leap
> had
>> never happened. The chronometric correspondence between the UTC and
> NTP
>> timescales continues, but NTP has forgotten about all past leap
>> insertions. In NTP chronometric determination of UTC time intervals
>> spanning leap seconds will thus be in error, unless the exact times of
>> insertion are known."
>>
>> When ntpv4 is standardized, the language changes to "leap at the end
> of
>> the current month".  
>>
>>
>> -----Original Message-----
>> From: questions-bounces+gdowd=symmetricom.com at lists.ntp.org
>> [mailto:questions-bounces+gdowd=symmetricom.com at lists.ntp.org] On
> Behalf
>> Of David J Taylor
>> Sent: Monday, December 15, 2008 9:39 AM
>> To: questions at lists.ntp.org
>> Subject: Re: basic questions about the leapsecond
>>
>> David L. Mills wrote:
>>> Guys,
>>>
>>> See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what
>>> actually is in the implementation. As visivle here, the Spectracom
>>> (GPS/WWVB) driver, ACTS telephone modem driver and WWV audio driver
> do
>>> correctly display leap information. The Meinberg GPS receiver, EndRun
>>> CDMA receiver and audio IRIG driver do not display leapsecond
>>> information.
>> []
>>> Dave
>> Dave,
>>
>> Thanks for that summary.  My own GPS system using the Garmin GPS18 LVC
>> and 
>> the official ntp code for FreeBSD also does /not/ show the leap
> second.
>> Is this something fundamental to all GPS - in that they don't indicate
> 
>> until nearer the end of the month?
>>
>> Thanks,
>> David 
> 
> Did you READ the message you replied to?
> 
> It seems quite clear to me!
> 
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 
> Did I miss something?  The question I replied to asked if any
> generalizations could be drawn about the behavior of various GPS
> devices, did it not?  Dave Mill's reply described exactly the behavior
> of the current distribution from ntpd land and a sampling of reflock
> driver operations.  It made no attempt to explain why some devices
> behave one way and some another.  For instance, I think it was Martin
> that noted that IRIG doesn't provide leap second info unless the 1344
> ToM enhancements are added.  It might be useful to understand that 1344
> only allows the leap bit to be set in the last 10 minutes of the day.
> Then you would understand that no audio IRIG driver will ever set leap
> well on its own.  As for GPS, the leap second warning is typically
> provided a few months early.  So, why do so many drivers not report it
> immediately?  The fundamental cause is likely that most of these
> drivers, including ones I've worked on, were written in the window from
> 1992 - today.  In that window, the ietf rfc defining NTP behavior
> restricts the driver to setting the bit until the day of the event per
> my posting.  Meanwhile, time has marched on and v4 has been available
> for a long time but it is not standardized and so there is no clear
> definition of whether what the refclock drivers do is correct or
> incorrect.  
> 
>>From my point of view, I find understanding the history and context of
> the unexplained creates a frame of reference.  Then I don't ask so many
> stupid questions.  At least hopefully I don't ask the same question
> twice.  

I don't recall just when the last leap second was.  The last one I 
remember was maybe three or four years ago.  It looked as if the entire 
world was confused by it and it took several hours for things to settle 
down.

Perhaps part of the problem was people adding the leap second at "local 
midnight" rather than at 0000 UTC.

We'll get through it somehow or other!




More information about the questions mailing list