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

[Martin Burnicki]

Steffen Nurpmeso wrote:
> 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).

Yes, and there needs to be an interface to timekeeping software in
general, i.e. provide glibc and friends with updated tz rules, and make
the leapsecond table available in a form that can be used by ntpd or ptpd.

In case of ntpd this means that either a leapsecond file has to been
written so it can be scanned by ntpd, or ntpd needs to support a
different different (binary?) format provided by a tzdist client.

Anyway, some basic infrastructure is available, but there's still some
work to do.

Martin