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

[Steffen Nurpmeso]

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

Yes, but no in sofar as that "some work" is definetely not enough
from my point of view.  It may very well be so from your Meinberg
NTP+ timekeeping point-of-view, but as a C(/C++) application
developer you are, i repeat a phrase from a message i have written
just a minute ago, in blind flight.  Well that brought us to where
we stand now, but of course this lets aside all the other
languages with a more complete time interface, and all the special
options that do exist and which people with special needs have to
use, e.g., a GPS receiver plus driver, for TAI time.

--steffen