[LEAPSECS] leap second roundup 2017

[Warner Losh]

On Mon, Oct 23, 2017 at 9:00 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> --------
>
> > By that logic one should avoid intervals spanning the end of February
> > because of leap days, and avoid any periods in the spring or fall (in
> > either hemisphere) that might span local DST transitions, [...]
>
> That is balderdash, and you know it:
>
> We know exactly when leap-days happen, and UTC doesn't have DST.
>

And the rules for leap days are fixed. They don't ever vary like leap
seconds do (since they are inserted observationally rather than
mathematically). Since the rules for leap days are fixed, you can write a
mathematical expression to implement them. And that expression is
relatively simple. And it can be testably verified via testing software.
You can't do that with leap seconds. While the rule for when they might
happen is fixed (though there's some disagreement among sources in end of
month vs primary / secondary times), the timing of them is unknown until 6
months prior. So because of that, nobody tests them: You can't tell me
today that a computer will, with absolute certainty, tick through a leap
second that might or might not happen on Dec 31, 2018. It's physically
impossible because literally nobody knows today that there will be one (or
not) with any certainty. you can't test that before you ship your embedded
system. On the other hand, you do know that Mar 1 follows Feb 28th that
year, but follows Feb 29th in 2020. You can test that before you ship a
system.

Sure, there are methods to distribute the leap seconds. They mostly kinda
sorta work. It's the "mostly" part that I base my statements with the
phrase 'with certainty' on. We're 5 decades on from the implementation of
leap seconds in 1972 and yet they still remain "mostly kinda sorta" working
when you consider all use cases. History has shown this, and likely will
continue to show it. I suspect the only way to get reliable leap seconds is
to say 'For the next decade, we'll do one every 18 months and publish in 5
years what we'll do the following decade' to keep the long-term drift fine,
but at the expense of DUT1 possibly having larger than 1s divergence.
Absent these changes, it will remain flakey and we'll continue to have a
proliferation of 'leap smear' schemes to paper over the leap second at the
expense of frequency stability (since most applications don't care for even
moderate frequency errors).

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20171023/12f8850e/attachment.html>