[LEAPSECS] Leap second smearing test results

[John Sauter]

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.

John Sauter wrote:

Dubious value: leap seconds cause UTC, and thus civil time, to track
the sun.  I don't regard that value as dubious.

Warner:

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.

John:

The idea behind leap seconds is to deal with a long-term problem by
making corrections so small that most people don’t care, or at most
laugh, when told about them.  For almost everyone, leap seconds are
inconsequential, and that’s a good thing.  The current definition will
do for about 1000 years, until the skew between the UTC and UT1 rates
gets large enough that we need a leap second before the end of the
month to keep abs(UTC – UT1) below 0.9.

=====

John:

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.

Warner:

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 too 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.

John:

Perhaps I am, as you say, excessively optimistic.  Maybe I am tilting
at a windmill, but I would rather light a candle than just scream into
the darkness.  I am attempting to address the systemic bias against
leap seconds in the world by making it easier to handle leap seconds
correctly than ignore them.  See my “Avoid Using POSIX time_t for
Telling Time”.

=====

John:

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.

Warner:

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.

John:

We are not slaves to standards—they exist to serve our needs.  If we
need to keep track of time accurately, and find a way to do so, the
standards will catch up.  POSIX time_t is fatally flawed when used for
the purpose of telling time.  The standard is so weasel-worded as to be
practically meaningless. 

I do not advocate changing the definition of time_t but instead that
programmers stop using it.  The tm data structure is a much better way
of recording an instant of time.  To encourage application programmers
to stop using time_t I have provided a package of subroutines which
manipulate the tm structure.  My hope is that application programmers
will use these subroutines because they are easier to use than
manipulating time_t directly, and will thereby handle leap seconds
correctly without any extra effort on their part.
    John Sauter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20161225/02802ada/attachment.pgp>