M. Warner Losh wrote:
> In message: <43E3E944.80406_at_usa.net>
> James Maynard <james.h.maynard_at_usa.net> writes:
> : Thanks, guys, for your feedback. Here's another iteration.
> :
> : The numbering of NTP seconds in the vicinity of a leap second seems to
> : differ from one document to another. Here I follow the NTP (version 3)
> : specification, RFC 1305, in which the Leap Indicator (sys.leap,
> : peer.leap, pkt.leap) is 01 if a positive leap second is to occur at the
> : end of the current UTC day, and 00 if no leap second is pending.
> :
> : UTC = 2005-12-31 23:59:59, NTP seconds = 3 345 062 399, LS_pending = 01
> : UTC = 2005-12-31 23:59:60, NTP seconds = 3 345 062 400, LS_pending = 01
> : UTC = 2006-01-01 00:00:00, NTP seconds = 3 345 062 400, LS_pending = 00
>
>
>
>>>The obvious question raised by this scenario is what happens during
>>>the leap second itself when NTP time stops and the clock remains
>>>unchanged. If the precision time kernel modifications have been
>>>implemented, the kernel includes a state machine that implements the
>>>actions required by the scenario. [[ At the first occurrence of second
>>>3,124,137,600, the system clock is stepped backward one
>>>second.]] However, the routine that actually reads the clock is
>>>constrained never to step backwards, unless the step is significantly
>>>larger than one second, which might occur due to explicit operator
>>>direction. In this design time stands still during the leap second,
>>>but is correct commencing with the next second.
>
>
> So internally, once we hit the leap second time, we step backwards.
> Some systems contrain the values returned from gettimeofday to not
> notice the step, while others do not. This talks about incrementing
> the time by 1 unit (usually a nanosecond or microsecond) while time is
> catching up.
>
> http://www.eecis.udel.edu/~mills/leap.html
>
> So it very much depends on if you are looking inside the kernel or
> outside the kernel for what the correct values are. If you freeze
> time, then doing a time exchange during a leap second is going to give
> bogus results. If you step it back, then it will give good results,
> but there are other bad effects.
>
> Basically, no matter what you do, it is broken (unless you tick in TAI
> time).
>
> Warner
>
>
>
Thank you. You are trying hard to educate me on this matter, and I
appreciate your efforts.
Following the link you gave me in this message, <>, I found a discussion
of how the leap second is to be handled in the NTP time scale. That
discussion includes the following table to illustrate the leap second
transition of 1998-12-31 23:59:60 UTC:
+-----------+----------+------------+----------+---------------+
| Date | Time | TAI Offset | NTP Leap | NTP Seconds |
+-----------+----------+------------+----------+---------------+
| 31 Dec 98 | 23:59:59 | 31 | 01 | 3,124,137,599 |
+-----------+----------+------------+----------+---------------+
| | 23:59:60 | 31 | 01 | 3,124,137,600 |
+-----------+----------+------------+----------+---------------+
| 1 Jan 99 | 00:00:00 | 32 | 00 | 3,124,137,600 |
+-----------+----------+------------+----------+---------------+
| | 00:00:01 | 32 | 00 | 3,124,137,601 |
+-----------+----------+------------+----------+---------------+
Funny, that's exactly what I wrote in my last iteration of my table!
In the NTP time scale, it is the last second of the UTC day, NTP second
number 3 124 137 600, that is repeated. The first instance of this NTP
second number is the leap second, during which (TAI - UTC) = 31 and the
NTP Leap Indicator is 01. The second instance of this NTP second number
is the the first second of the new UTC day, during which (TAI - UTC) =
32 and the NTP leap indicator is 00. You can distinguish the leap
second (while it is occuring) by the fact that it is the last second of
the UTC day (time of UTC day = 23:59:60) and that the NTP Leap Indicator
is 01. You can distinguish the first second of the new UTC day by the
fact that, of the two seconds with the same NTP second number, it is the
one that has the NTP leap indicator set back to 00.
Note that according to the write-up to which you referred me, it is
NTP second number 3,124,137,600 (not 3,124,137,599) that is repeated.
NTP second number 3,124,137,599 is the *next-to-last* second of the day,
not the *last* second of the day.)
--
James Maynard
Salem, Oregon, USA
Received on Fri Feb 03 2006 - 23:45:15 PST