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

[Steve Summit]

Warner Losh wrote:
> On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> >> 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.
> >
> > Could that be solved with 2 functions in the API, one for N seconds from now,
> > and a second for at some future date/time specified in Y/M/D/H/M/S format
> > rather than something like a time_t?
>
> Only partially (meaning only assuming every day has exactly 86400
> seconds). These operations are possible today, since the former is +=
> and the latter is timegm(), sorta, but neither groks leap seconds.

I think we can do better than that, even today.  If you want
to do something in N seconds, schedule a conventional alarm.
(And, yes, using today's code, you'll always get N seconds that
ignore leap seconds.)

But if you want to do something at a particular future time,
and you don't care (or can't predict) exactly how long from now
that'll be, you can do that today, too, with clock_nanosleep and
the TIMER_ABSTIME flag.

In principle, it's straightforward to define meaningful behavior
for both relative and absolute timers which run on Posix, TAI,
or true-UTC timescales -- that is, with clockid tags of
CLOCK_REALTIME, CLOCK_TAI, or CLOCK_UTC.  Implementation of some
of the combinations is likely to be difficult, but hopefully not
impossible.  (CLOCK_TAI is already in the newest Linux kernels,
but I'm not sure how well it works; CLOCK_UTC is, shall we say,
emerging.)

One key point is that while scheduling a future event to occur
at an absolute time does indeed necessarily require naming that
time, this does not -- repeat not! -- become impossible just
because we can't know how many leap seconds might occur between
now and then.  If the true-UTC representation is properly
designed (that is, if it is *not* realized as, say, a monotonic,
leapsecond-observing count of seconds since the epoch), you
can construct a future true-UTC timestamp, using a new mktime
variant, just as easily and accurately as you can construct a
future time_t value.  (In other words, we should not have to
assume 86400-second days to do these things.)