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

[Warner Losh]

On Fri, Dec 30, 2016 at 10:11 PM, Rob Seaman <seaman at lpl.arizona.edu> wrote:
> On Dec 29, 2016, at 1:35 PM, Warner Losh wrote:
>
> 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...
>
> Of course, MacOS is largely based on legacy code...
>
>
> Sixteen years ago, MacOS was a completely different operating system than on
> this MBP.
>
> The issue is what happens over the next fifteen years.
>
>
> That's not even remotely true. The GUI is completely different, but the core
> of the OS hasn't been rewritten in the past 15 years.
>
>
> Let’s back that up. During the  period, approximately 15 years long, that a
> small faction sought to have the ITU redefine UTC, Mac OS X has lived its
> entire lifecycle. Sixteen years ago, Mac OS 9 was a completely different
> beast. For that matter, iOS and Android are both less than a decade old.

You really don't know how much code is reused. Mac OS X has code
that's at least 40 years old in it. It is the fusion of Mach VM and on
a BSD kernel, both projects date back to the 70's. It uses the BSD
libc, as does Android (which is basically Linux kernel plus a BSD
userland plus cool stuff from google for Java and the like). All these
code bases are at least 30 years old. They aren't, as you say,
completely different. In fact, they likely contain some of the same
ancient code in them. Nothing is ever re-written from scratch. Even
Linux, whose kernel was written from scratch, imports tons of code
whose histories pre-date linux (gcc, X11, etc). iOS is MacOS rebranded
and ported to ARM. None of these have been written from scratch in the
last decade. Even the venerable IANA timezone database and code is
pushing 30 years at this point.

> In the coming decade, one is confident that lots of other software will be
> written and rewritten. It will be better software if it acknowledges factual
> reality as its underpinning.

And POSIX time_t can't represent leap seconds any more today than it
could in 30 years ago. Until this fundamental issue is resolved, no
forward progress is possible.

The "factual reality" is a construct of man. UTC is arbitrary in its
limits of 0.9s. There's nothing magical about 0.9s except that it
limited the errors from celestial navigation to a tolerable amount in
the days before GPS. Sure, mean solar time is not synchronized with
atomic time. That's reality. But what we adopt for civil time need not
be mean solar time. That's an invention of man as well. It's
tradition, sure, I'll grant that, but it isn't a fundamental constant
of the universe. Go only as far as Mars and everything changes...

> The argument appears to be that POSIX is such crap that we have to degrade
> other technologies. This may be aligned with the zeitgeist of 2016, yet
> remains oddly unpersuasive.
>
> It's only unpersuasive because you don't understand how long old code sticks
> around.
>
>
> Steve Allen and some others here from the astronomy community may be amused
> to have such a statement directed to a long time member of astronomy's IRAF
> group.
>
> POSIX dates to 1988, about the time I joined the IRAF group, though I had
> coded in IRAF starting around 1984. IRAF is layered on a virtual OS / kernel
> architecture and is coded in a highly portable C-like preprocessor language.
> The verbatim source runs (or ran) on various flavors of Unix, on VMS, on
> Data General’s OS. The code base is roughly of the scale of Linux.
>
> As IRAF’s Y2K tsar I understand how old code can be updated to support a new
> timekeeping API.
>
> Astronomy’s FITS image / table data format also predates POSIX, by an
> additional five years or so (late 1970s). This is a quirky international
> standard with a rather arcane process for changing the standard. Steve and I
> and likely others here are members of various FITS committees that navigate
> proposed changes. A checksum proposal was adopted into the standard this
> year that I introduced in 1994. The FITS world coordinate paper on time that
> Steve coauthored took a lightning fast decade or so.
>
> Over the next decades we likely all believe that time and timekeeping will
> become more important, not less. As such, software and systems and standards
> relating to time will benefit from attacking the issues head on. At the very
> least preserve the current UTC standard for backwards compatibility while
> having some committee of the ITU or BIPM design (or attempt) a better
> mousetrap.

Carefully written code can cope. However, the standard APIs don't
allow people to cope. You have to talk the standard APIs if you want
your code to be portable. The standard APIs don't have a way to
express the leap second unambiguously. That's the fundamental problem.
And the prevailing attitude has often been "it's just a second, why
bother fixing it" in so many places that there's no mindshare to get a
POSIX extension that groks leap seconds. Since the standard APIs don't
have leap seconds working w/o any extra effort, most things get them
wrong.

> The current UTC standard has a lot of flexibility regarding scheduling. It
> is a means to an end. By all means debate ways to improve the logistics of
> its realization of mean solar time.

Nobody seems to want to have that conversation. It's been proposed,
and shot down, that we make our best guess 10 years out and adjust
from there. It's been proposed that we announce 2 years out that the
current models can predict with 99% certainty, that's been shot down.
It's been proposed that we add a leap second on a schedule that
matches the long-term rate of change (so fewer now, more later), also
shot down. All shot down because DUT1 < .9s is sacrosanct now.

> I'll note that while one can run with TAI or GPS time, and one has been able
> to do that for at least 20 years that I’m aware of, it doesn't solve the
> problem. If it was that easy, we'd be doing it already.
>
>
> We are doing that already. The GPS time scale exists because pragmatic
> engineers decided to solve the problem in front of them. Many others use
> TAI, but more don't because plans for improved support similar to the Torino
> TI resolution were subject to foot dragging while a small faction sought
> circularly to redefine UTC to remake it into the equivalent of TAI. This has
> never been about improving access to interval time, it has been about
> denying access to solar time.

GPS time exists because leap seconds were a horrible idea and they had
to invent their own thing. But computers and business don't run on GPS
or TAI time like some specialized systems can. They are required in
many cases to run on UTC, and the state of the art of the most basic
parts of the system is such that we have to do these horrible spearing
things around leap seconds to even come close. Too many things get it
wrong, and fixing them all is quite costly.

> Time of day is a different problem than interval time. Geophysics exists.

I find that argument unpersuasive. Time of day matters because I need
to know when to go to work. DUT1 < 0.9s isn't required for that. Time
of day is what the close says now, not when the sun comes up or when
it is over head. The use of time by society is evolving, and the
close, rigid coupling to the spinning globe may not make sense. The
de-coupling may not make sense either, but the current
unpredictability beyond a half a year is just nuts.

Warner