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

[Steffen Nurpmeso]

Martin Burnicki <martin.burnicki at burnicki.net> wrote:
 |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.
 ...
 |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

And especially that the information of a leapsecond is permanent
is notable; tzdist added leapseconds, but it requires some
processing power (xml, json), unless it adds an easy standardized
binary access protocol, like e.g., CBOR (this becoming popular
across IETF, so it may only be a matter of time).

--steffen