[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Martin Burnicki]

Steve Summit wrote:
> Tony Finch wrote:
>> Even though NTP can represent current UTC correctly, it often gets leap
>> seconds wrong. It does not give confidence that we will be able to
>> reduce bugs by teaching more code about leap seconds, when NTP cares
>> about time and gets it wrong, and most code cares much less.
> 
> I feel a little bit like I'm rearranging deck chairs on the
> Titanic with this kind of suggestion (and I know this isn't the
> NTP list), but the appalling number of NTP servers that got it
> wrong this time around made me think that another extension NTP
> needs is a way to announce an upcoming leap second (i.e. one it
> knows about) more than 24 hours in advance, so that those of us
> who care can confirm that the servers we're using are going to
> get it right.

I don't believe this is necessary. If the existing ways to announce a
leap second are used correctly then ntpd gets it right, in that it
notices the kernel of the upcoming leap second, and also forwards the
announcement out to its clients.

However, as mentioned in my other post, if the information passed to
ntpd is not correct then it can't act correctly.

If you introduce another extension to provide leap second information
then this even becomes more confusing: what if the extension field
announces a leap second, and the upstream server(s) / refclock(s) / leap
second file doesn't? Or any variation of the above?

If you provide your NTP daemon with a *current* leap second file then
your ntpd knows about 6 months in advance if a leap second has been
scheduled, and it also knows the TAI offset it can pass down to the kernel.

There is the new tzdist protocol which could be used to update the leap
second table automatically, and there is a proposal by Poul-Henning Kamp
how this could be done via specific DNS queries:
http://phk.freebsd.dk/time/20151122.html

Martin