[LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Thu, Dec 29, 2016 at 4:29 AM, Rob Seaman <seaman at lpl.arizona.edu> wrote:
> Warner is staging a spirited defense of POSIX. Such a stalwart champion
> deserves a more worthy cause.
>
> POSIX time_t says they don't exist. Therefore, they don't exist.
>
>
> POSIX, meet physics.

There's nothing that says that DUT1 < 0.9 is sacrosanct. It isn't
physics, it's about convention. But we've had this argument many
times.

> There's millions of lines of code written to POSIX with the mistaken
> assumption that they are implementing time correctly. Changing it all, or
> even a large part of it, is unlikely to happen.
>
>
> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X
> was launched in 2001.

Could have, but didn't. In the interim no contender for best ever time
library that solves the leap second problem emerged and was accepted.

Of course, MacOS is largely based on legacy code, so in its core
libraries little code was added around time. But that's a quibble
about the example.

> UTC may well be superior to POSIX's notion, but that’s entirely besides the
> point.
>
>
> It is the only point.

It all depends on the metrics you use to judge it by.... Is time of
day more important or interval time more important.

> While it might result in a better world if POSIX were able to change, it
> isn’t.
>
>
> Placing POSIX in the same “too stupid to fail” basket as the U.S. Electoral
> College seems a weak strategy.
>
> The marketplace has effectively voted with its feet, and change would be too
> expensive.
>
>
> But change is what is proposed. That being the case, the simplest change
> would be to define a new timescale. Call it “GNU” for "GNU is Not UTC”. Add
> one statement to the POSIX standard:
>
> “After <date> all references to UTC in the POSIX documents, or to
> timekeeping generally, will be taken to refer to the GNU time scale, defined
> by <document>.”

You've obviously never dealt with pervasive standards in coding that
date back to the 70's that are nearly impossible to change. Doing that
by fiat isn't going to work.

> Or simply adopt GPS or TAI, which already have the precise behavior desired.
> Commercial devices already exist (and are already widely deployed) that
> implement high precision GPS and TAI.

Won't work. Been proposed and rejected many times.

The basic problem is that things don't work by default. They can't
work by default with the current standards, as defined by existing
practice. POSIX dropped the ball here in some ways (though to be fair,
they were codifying existing practice that dated back to the mid
1970's in UNIX: prior to that epochs changed every couple of years).

If there was an easy solution, it would have emerged by now. Trouble
is that the details are quite difficult to get right even if you get
the standards issues out of the way. And it's for a problem that
people sneer at (only a second, why do I care), so there's little
support for spending boatloads of money to fix it. The problem is that
you never know if the following code has a leap second issue or not.
Let's suppose for a minute we redefined time_t to be TAI. Let's
further suppose that we can perfectly transmit knowledge about leap
seconds to every machine on the planet that's doing time
synchronization well enough to care. Let's also suppose the numerous
other technical issues are sorted out. How do you know if the
following code has issues with leap seconds or not:

time_t foo;
foo = get_some_time();
foo += 60;
do_something_at(foo);

Does this code say "do something in 60 seconds" so it will slip 1
second within the minute over a leap second. Or does it say "Do
something one minute hence at the same offset within the minute?" For
the casual observer, those two statements are the same. but to the
computer, they are different. And it isn't something that's easily
adaptable to easy detection by the compiler because it's how boatloads
of code is currently written. Many of the y2k bugs were caught because
the patterns there are easier to automatically scan for. Yet this
example illustrates that it can be hard to divine intent.

One could imagine having a more complicated structure that could cope
with the inherent ambiguity in future times. I can't say "schedule an
event exactly 1 year from now" for example without it. I need
additional metadata around to know if I want it to happen at the same
time of day on the same date or if I want it to happen after than many
seconds have elapsed. You can't convert a putative UTC time to TAI
time until you are within 6 months of that time (the current
announcement schedule) because if you try to compute that time too far
in the future, it will change. Absent metadata, you'll have the wrong
time. It also means that any interval you compute about a future set
of times can change after you've computed it in the light of new data.
It's this aspect of the problem that leads me to say it's unsolvable:
future UTC is inherently ambiguous because it is tied to a rotating
earth and only through observations can we know when to insert a leap
second.

As an aside, UTC could be made more predictable if a schedule was
announced like we do leap days. We can be off by several days because
of leap days at any given time, but over the long haul we stay in
sync. This change to UTC to give it a predictable schedule at the
expense of a little more slop around DUT1 could make many of these
issues more tractable, and make it possible to write software that can
just work by default. But that's fiercely opposed because of the
uncertainty that a DUT1 of 2s or 5s or 10s might cause. We know for
sure it messes up some telescopes that have proprietary aiming
software that requires that UTC be < 1s so they can acquire the target
star for observation before centering it. It's unclear what else
breaks, but nobody is eager to find out. This uncertainty will lead to
continued inaction as well. We know the day out several thousand years
so everybody gets it right, but don't know the time out more than 6
months. Regardless of all the other technology that UTC enables, this
is a deep flaw in how UTC is currently realized and is, imho,
fundamental to what makes it a hard problem to solve.

But we get back to the arguments against this thing "you want to spend
how much to retrofit everything so you can get that level of
precision?" The "it's only a second" is the enemy of ever getting this
right, because there's no perceived value. Some people will try hard
to get it right, but most won't care, or even know they have created a
problem. Since most people won't fix it, de-facto POSIX runs the show,
which has no leap seconds. That's why I said it has de-facto redefined
UTC. The impedance mismatch here is growing greater year by year, not
diminishing.

Having said all that, I totally get why people want UTC to have leap
seconds. I get what that enables. I'm suggesting, though, since
software is running life more and more, we'll see stop-gap solutions
like the smear paper over things until the stop-gaps get too much of a
hassle to do and there's a growing call to harmonize the two world
views in favor of POSIX. We aren't there yet, I'll freely admit. But
the last 16 years I've been involved in the problem, there's been
little movement to a real solution to the mismatch and I'm pessimistic
that the hard line of UTC can be maintained forever.

Warner