[ntp:questions] Re: What went wrong with the leap second
Ulrich.Windl at RZ.Uni-Regensburg.DE
Fri Jan 20 14:01:21 UTC 2006
Martin Burnicki <martin.burnicki at meinberg.de> writes:
> > Is there a difference in how GPS and DCF77 handle the leap second?
> DCF77 starts announcing the leap second 1 hour before it is inserted.
> The GPS satellites start broadcasting the upcoming leap second shortly after
> this has been announced by the IERS. The last leap second has been
> announced by the GPS satellites since middle of July, 2005.
Another good question is how NTP will behave on different references showing
different leap bits: Will it absolutely trust the current sync peer, or will
it make a majority decision? I think the former is true. Also, can a bit
mistakenly set via one reference be cleared by another reference? (Or
malicuosly be reset?)
> How these announcements are passed to ntpd depends on how the leap second
> announcement is handled by the firmware of the DCF77 or GPS receiver, how
> the driver module for that particular device evaluates that announcement
> and passes it to the ntpd loop filter, and of course by the version of
> ntpd, since there have been some modifications across the versions.
> > Do some NTP implementations insert the leap second at 23:59:59 local time
> > rather then UTC?
> Not that I'm aware of. It this has happened this was a bug.
Remember that DCF77 is local time always, while NTP uses UTC all the time. Now
if the timezone is configured incorrectly on some stratum-1 server with a
DCF77-only config, the announcement (and the leap second) might come at the
wrong moment, but that reference would be off alll the time. Also distinguish
between announcement and insertion (deletion) of a leap second.
> Normally ntpd works exclusively with UTC, but on the other hand I know there
> are people who think this is not what they need, and pass a reference time
> to ntpd which is local time rather then UTC. Such an ntpd might distribute
> local time rather than UTC, and since ntpd was not aware of this, it would
> insert the leap second at what it thinks is UTC midnight, but in fact is
> local time midnight.
(We say the same here)
> Maybe our leap second info page is helpful. Please have a look at
> Hope this helps.
> Martin Burnicki
> Meinberg Funkuhren
> Bad Pyrmont
More information about the questions