[ntp:questions] Leap second functional question

Unruh unruh-spam at physics.ubc.ca
Mon Feb 18 17:02:40 UTC 2008


Dean Weiten <dmw at weiten.com> writes:

>Thanks, that was what I was looking for.  You are saying that I didn't 
>have it right, how about this.

>If I were to say "the timestamp will be what it would be outside the 
>area of the leap second, regardless of whether or not a leap second is 
>inserted or deleted", would that be correct?  For instance, the 
>timestamp 3 seconds after a leap second would be the same as without the 
>leap second?

In theory yes. In practice, maybe not. It may well take a while for any
specific machine to actually work through the leap second. 


>Adding a Leap Second
>====================
>As an example, let's say that there was a leap second to be added on 
>2008-01-01 at 00:00:00.

>If the leap second indicator bits turn off at the **end** of the leap 
>second it announces, and if the timestamp **holds** for the leap second, 
>then the values returned in this contrived example might look like this:

>Time                        Timestamp           Leap Second Bits
>----                        ---------           ----------------
>2007-12-31 23:59:58.0000    CB2400FE.00000000        01
>2007-12-31 23:59:59.0000    CB2400FF.00000000        01
>2007-12-31 23:59:59.5000    CB2400FF.80000000        01
>2007-12-31 23:59:59.9000    CB2400FF.E6666666        01
>2007-12-31 23:59:60:0000    CB2400FF.FFFFFFFF*       01
>2007-12-31 23:59:60.5000    CB2400FF.FFFFFFFF*       01
>2007-12-31 23:59:60.9000    CB2400FF.FFFFFFFF*       01
>2008-01-01 00:00:00.0000    CB240100.00000000        00
>2008-01-01 00:00:01.0000    CB240101.00000000        00

>* - Undefined, fraction can be any value but would generally be held to 
>no less the value of the last legitimate call during the previous second 
>2007-12-31 at 23:59:59.

I think that the right answer is "held to be greater than the value of the
last legitimate call. Ie, the time always increases.


>NB time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as they 
>would have been without the leap second addition.

They should be. Whether or not they are may well depend.



>Deleting a Leap Second
>======================
>Another example, let's say that there was a leap second to be removed on 
>2008-01-01 at 00:00:00.

>Then the values returned might look like this:

>Time                        Timestamp           Leap Second Bits
>----                        ---------           ----------------
>2007-12-31 23:59:58.0000    CB2400FE.00000000        01
>2007-12-31 23:59:58.5000    CB2400FE.80000000        01
>2007-12-31 23:59:58.9000    CB2400FE.E6666666        01
>2008-01-01 00:00:00.0000    CB240100.00000000        00
>2008-01-01 00:00:01.0000    CB240101.00000000        00

>NB again time stamp of 2008-01-01 00:00:00 and 00:00:01 are the same as 
>they would have been without the leap second addition.


I believe this to be the case. However, I am not an ntp expert so I hope
that the people who really know (Mills?) can correct any errors I make.


>Unruh wrote:
>> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>> 
>>> Dean Weiten wrote:
>> 
>>>> As an example, let's say that there was a leap second to be added on 
>>>> 2008-02-10 at 23:59:59 (hmm, or is that 2008-02-11 at 00:00:00?).  This 
>> 
>>> It would be added at 2007-12-31T23:59:60 or 2008-06-30T23:59:60.  For a 
>>> deleted second, 2007-12-31T23:59:59 or 2008-06-30T23:59:59 would be deleted.
>> 
>> He is asking how it is added or subtracted. 
>> His date of Feb 11 was wrong, but was a trivial part of his question. He
>> wants to know HOW the second is added or subtracted. 
>> 
>> NTP time is UTC which assumes 86400 seconds in each and every year.
>> Exactly. Ie, those leap seconds are "forgotten" after they occur. 
>> Thus UTC does not tell you how many actual seconds occur between date A and
>> date B/ There is a time scale,  TAI which is the actual number of seconds.
>> There have apparently been debates as to whether ntp should keep UTC or
>> TAI. The latter makes more sense. The former is easier for operating
>> systems to deal with since clocks and legal stuff it UTC (with timezone
>> corrections). 
>> 
>> AFAIK ntp deletes a leap second by jumping, and inserts a second by
>> stopping the clock for a second. -- well I am not sure that ntp actually
>> does that. It may just hand the leap second to the kernel and hope the
>> kernel does the right thing. If the kernel does not, then ntp spends the
>> next hour readjusting the clock. 
>> 
>> 




More information about the questions mailing list