On Wed, Jul 15, 2015 at 10:37:10PM -0400, Philip Gladstone wrote: > Is there an official recommendation on what to do with the leap second bits? > In particular for implementations that are not based on the standard NTP > code.
The NTPv4 RFC includes a minimal example code, which simply takes the leap value from the selected system peer without any sanity checking. I'd not recommend doing that. For the safest approach in an NTP client I'd suggest: - if tracking multiple sources, take leap of 1 (insert) or 2 (delete) only when more than half of the sources agree on that value - if the local clock says it's not June 30 or December 31 (in UTC), treat leap of 1 or 2 as 0 (no leap) - if leap of 1 or 2 is accepted, ignore any measurements made when the local clock is closer than few seconds (e.g. five) to the leap second, both before and after the leap For an NTP server: - report leap of 3 (unsynchronized) to the clients when the local clock is in or very close (e.g. half a second) to the ambiguous second on the NTP time scale (23:59:60 UTC), the local clock needs to be corrected in that interval - set leap to 0 shortly after the leap second, don't wait for new replies from upstream sources This is how it's implemented in chrony. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
