Anthony DeRobertis wrote:
Simon Arlott wrote:RFC 2030 doesn't even specify when to add/remove a leap second:Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current dayThat would seem to say, though, that it shoudln't be set before Dec 31.
I'm not interested in SNTP so I wouldn't accept it as justifying why it's wrong to have the leap bits set so early, it's RFC clearly states that it should only be used at high stratum, that nothing should be dependent on another SNTP client, and that NTP is required for a reliable primary system - so SNTP servers shouldn't really exist in the pool.
SNTP clients may use it though and the SNTP RFC says that the NTP RFC isn't needed to implement SNTP.It's actually bit pointless discussing this anyway since NTP has no way of specifying when the leap second occurs - only that unsetting the bits indicate that it has occurred and by the time clients have received leap=00 as it propagates through the network most of them would have adjusted their clocks as if they were 1 second out.
Can the leap bits become unset if there are servers sending it? Couldn't two peers decide to stay at leap=01 because of each other?It would be interesting to know if the severs that are sending leap=01 have been configured to do so since the announcement of the leap second, or if they've been manually configured like that for years.
-- Simon Arlott
signature.asc
Description: OpenPGP digital signature
_______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
