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

[Warner Losh]

On Fri, Dec 30, 2016 at 7:28 AM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> Never having done kernel programming, this doesn't sound logical
> to me.  You have a clock source and a conversion algorithm.  That
> runs every time, maybe even millions time a second?  Maybe kernels
> exist which don't do any work unless there is real work to be
> done, due to I/O or application requests etc., then synchronizing
> on soft startup only, a.k.a. less often.

Kernels don't work that way at all.

> It appears to me that it would be a single additional subtraction
> to get to UTC, would that time signal be tracked as TAI.

At any given instant, you might know how many seconds UTC and TAI
differ by. That's the easy part. However, you might not always know
that, and for any second that's more than 6 months in the future, it's
impossible to know how to convert.

>  |One could imagine having a more complicated structure that could cope
>  |with the inherent ambiguity in future times. I can't say "schedule an
>
> So there is no ambiguity for CLOCK_TAI.

There is ambiguity in CLOCK_TAI because all sources of time are UTC.

> The ambiguity for UTC is to adjust time for our home planet, or
> what remains of it now that we listen to some middle-age eight
> cylindre blues that is to say -- e.g., ~58 percent loss of species
> in a fourtyfive years study from i think WWF it was?
> Yes, yes, i know about that great future with those Big Macs that
> have grown in the genetical laboratories etc., and the cloned-back-
> to-life green plants everywhere (take for example that fantastic
> invention of the "CityTree", how fine that is).
> Until then i realize -- i very _much_ realize when i look out of
> my window, to say the truth -- that the sun and the light and
> warmth it brings is a very crucial aspect of not only my
> subconsciousness, and i now start looking forward impressable to
> the leap second that is to occur to bring us in sync again.  Yes.

I doubt very much you can tell an error of DUT1 being even as small as 60s.

>  |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
>  ...
>
> Yeah, sorry, but that is what it is.  Those financial warriors
> need it for timestamps, with subsecond precision.

"It is what it is" means that it's basically an intractable problem.

>  |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
>  ...
>
> But what is the application you need this for?
> You want to know future dates with subsecond precision --
> Armageddon won't happen, thanks to Bruce Willis -- but never cared
> for correct date handling of the past.  No one ever did.
> One day you will turn around and find nothing but scorched earth
> behind your back.

Designing an API that can't handle all reasonable uses of time means
you are setting yourself up for failure. This is another manifestation
of the "it's only a second so why bother" attitude that will continue
to mire us in the unsatisfying situation we're in now. Trying to give
me a straw-man argument about what use is it means that you're saying
we can't solve this problem or that I'm crazy for trying. Yet it's one
of the very real issues that one confronts when trying to deal with
actually solving the problem. It's the primary cause of my pessimism.

Warner