Re: REMINDER: LEAP SECOND

[Mel Beckman <mel () beckman org>]

Harlan,

Help me understand why there is a serious risk of going back in time. I acknowledge that there is a remote chance of a 
backstep, but the probability seems very low.

Suppose I disable my NTP service five minutes before a positive leap second occurs, so that no server in my network can 
query it. These servers will then run on their own internal clocks. Then, five minutes after the leap second, I 
re-engage NTP. Assuming a high degree of local oscillator fidelity, imagine the clock drift is zero. The result is that 
NTP will report one second older than the time currently in my server, i.e. exactly five minutes after the 23:59:60 
leap second.

Thus even systems, such as Unix, where 23:59:60 does not exist in the UTC implementation, the timestamp the server sees 
from NTP is not the potentially code-crashing 23:59:60, but a perfectly rational 00:05:01. This is what my server’s NTP 
client compares with its internal clock of 00:04:59. NTP's target time is in the future, so there is no risk of going 
back in time. NTP gradually increments the local time to converge on NTP’s time.

In the alternative case of a negative leap second, following the NTP clock discipline algorithm, the NTP client 
amortizes the one-second reverse jump, specifically in order to avoid setting the clock backward: the local time will 
be gradually adjusted again via the clock discipline algorithm until local and NTP times converge. Although the offset 
is more than the 125ms step threshold, stepping a full one second backward is still statistically unlikely.

It may be that I’ve misread the NTP specification in RPC-5905 and its antecedents, as well as the leap second 
historical records of problems. But the disabling-NTP-prior-to-leap workaround seems to bypass all the documented 
leap-second live lock hangs and other bugs..

 -mel


On Jun 22, 2015, at 4:06 PM, Harlan Stenn <stenn () ntp org<mailto:stenn () ntp org>> wrote:

Doug Barton writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 6/19/15 2:58 PM, Harlan Stenn wrote:
Bad idea.

When restarting ntpd your clocks will likely be off by a second,
which will cause a backward step, which will force the problem you
claim to be avoiding.

There are plenty of ways to solve this problem, and you just get to
choose what you want to risk/pay.

You misunderstand the problem. :) The problem is not "clock skips
backward one second," because most of the time that's not what
happens.  The problem is that most software does not handle it well
when the clock ticks ... :59 :60 :00 instead of ticking directly from
:59 to :00.

POSIX NEVER shows :60.

THAT problem is avoided by temporarily turning off NTP and then
turning it back on again when "the coast is clear." Most software can
handle the "clock skips forward or backwards one second" problem
fairly robustly,= and as Baldur pointed out by doing the reset in a
controlled manner you greatly reduce your overall risk.

Time going backwards is deadly to a number of applications.

But apparently not to applications you care about.

You're also not doing anything where somebody is going to get sued
because a timestamp is off by a second.  There are people for whom this
is a very real risk.

H