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

[Warner Losh]

On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit <scs+ls at eskimo.com> wrote:
> 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.)

Other systems don't have this quite yet, but I'd love to see it more
widely implemented. Is there a spec for this yet, or is it just
whatever code is noodling around in Linux?

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

To do this, one would need to tell the kernel that a new leap second
is introduced. That's not too bad, but you'd also need to then run
through all the timers in the system to adjust the time that the UTC
timer was going to fire to be a new time (by removing and inserting it
into the right list). While there are a number of different clocks
that can be reported, timeouts are still in the absolute ticking
monotonic thing. Doing a time conversion on every timeout is likely to
be too expensive since they get called a lot and tend to be the
critical path.

But I'm curious how you'd represent a leap second in this scheme? I'd
like to schedule a timeout in the UTC time during the leap second
(because it's the next second, or in 5 minutes or whatever, not
because there's something special about it, but because there
shouldn't be something special about it). How is that encoded into
time_t? Its easy to encode in TAI time, but not so easy to encode in
UTC time. It's especially troublesome if the kernel decides that there
really isn't going to be a leap second at midnight for some reason
(like a bad ntp server leaked the wrong data which was later
corrected). It might be easiest if there's a flag on the UTC timeouts
that could be adjusted across such events... Not ideal, but not
horrible.

Warner