[LEAPSECS] Leap second smearing test results

[Warner Losh]

On Fri, Dec 23, 2016 at 8:37 AM, John Sauter
<John_Sauter at systemeyescomputerstore.com> wrote:
> On Thu, 2016-12-22 at 21:50 -0700, Warner Losh wrote:
>>
>> These are the reasons I hate leap seconds: they are of dubious value
>> and cause all kinds of havoc because nobody expects them to work, and
>> the programming standards are written as if they don't exist.
>>
>> Warner
>
> Dubious value: leap seconds cause UTC, and thus civil time, to track
> the sun.  I don't regard that value as dubious.

So do time zones. People that care about DUT1 can get it over the
internet these days. UTC isn't precise enough for them anyway. There
are some folks with legacy gear that can't easily be changed (mostly
telescopes), so I feel for them since often they have hired someone to
build the telescope, maybe years ago, and changing now would be quite
costly. The error that leap seconds correct is ~21 parts per billion
(today). Leap days correct an error of ~1.1%, so the comparison isn't
too apt. The value is mostly theoretical, but they won't be around
forever since the quadratic acceleration of leap seconds will mean in
the future we'll need to come up with a better way to cope. Leap years
are still good for maybe 10k years before we have to adjust. Leap
seconds are unlikely to be viable in a thousand years.

> Cause all kinds of havoc because nobody expects them to work:
> expectations can be changed by fixing the applications so that they do
> work.  Fixing applications takes time, and expectations will lag behind
> the fixes, but given time the problem is not unsolvable.

The problem is almost unsolvable. Changing expectations is impossible.
Leap seconds are too flakey to teach once in programming class. They
are too unpredictable to provision long enough in advance for the life
of a system (unlike leap days). They are just a second, so nobody
allocates resources to fix issues: they just live with the results.
There's been no sign that things have improved in the last 15 years
since I started working in the field, so while I admire your optimism,
I'm to jaded to share it. Until you can address the systemic bias
against leap seconds in the world, they will continue to be the
bastard child of time keeping, with only the most pedantic getting
them right.

> The programming standards are written as if they don't exist: no longer
> completely true--POSIX, for example, implicitly acknowledges their
> existence before requiring applications to pretend they don't exist.
> Standards follow practice: when applications routinely handle leap
> seconds correctly, their techniques will be incorporated into
> standards.

POSIX time_t says they don't exist. Therefore, they don't exist. There
is some lip-service to leap seconds in struct tm, but until time_t can
cope, the standard is hopelessly broken. The number of programs that
use time_t is huge, and almost none of them get leap seconds right
(the one that do have to use extra data not covered by the standard to
get it right). The POSIX committee is actively hostile to changing
this state of affairs and has made the engineering decision that it's
just a second, and people don't get it right, so they simplify the
problem by assuming they don't exists, or if they do they are handled
outside of the standard somehow because there's no way to
unambiguously encode them in the standard for time_t.

So, you can say those things, but I'm not at all optimistic that
things will change.

Of course, that won't change the fact that they are part of the
standard, and something more sensible than throw a 1 second error (or
worse) needs to happen. Especially the "or worse" part given the
number of bugs related to leap seconds in the past that were more than
just a small time keeping error. So I get that computers should
implement them right, but until they are "right by default" we'll need
skewing to paper over the worst of it.

Warner