M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
James Maynard <[EMAIL PROTECTED]> 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
