[LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-04 09:15 PM, Steve Summit wrote:
> Martin Burnicki wrote:
>> If we don't look only at the kernel and ntpd, but also consider PTP,
>> then there's still the question if if wouldn't be better to let the
>> kernel time run on TAI, and derive true and/or smeared UTC from it.
> Right.  At first when I was trying to implement CLOCK_UTC, I
> lumped it in with the problem of reworking the kernel's internal
> clock, but actually, they're separate problems.  Although I
> *have* reworked the kernel's internal clock (Linux calls it
> 'xtime'), it's expensive, and I'm now considering it among other
> options, of which there are at least three:
>
> 1. Have xtime keep true UTC, as I've been doing so far.  This was
>     always my first choice, but it ends up being majorly invasive,
>     and I fear the Linux kernel developers will lynch me if I so
>     much as mention it.
>
> 2. Have xtime keep TAI.  This has the advantage that it's not at
>     all wrong or kludgey to represent TAI as a simple count of
>     seconds since the epoch, which of course xtime already is.
>     The objection, as mentioned here pretty regularly, is that if
>     you want to be able to set the clock from UTC, and deliver
>     UTC, you always need to know TAI-UTC, so if you don't have it
>     (if you're not on the net, or if you don't faithfully receive
>     it early enough during boot) you're sunk.  But I'm now
>     thinking that the work involved in assuming TAI-UTC=0 in that
>     case (and remembering that we can't, for example, return
>     success if someone asks for clock_gettime(CLOCK_TAI), and
>     remembering to fiddle things if we learn TAI-UTC later) may
>     end up being less than the work involved in #1.
>
> 3. Keep xtime just about the way it is, augmented with a
>     well-defined leap-second flag (along the lines of the TIME_OOP
>     flag returned by adjtimex) so that CLOCK_UTC can still be
>     derived from it with full accuracy.
>
> Number 1 was my strong preference at first, because I very much
> wanted a kernel that kept "true UTC" internally, with no kludges
> or circumlocutions, and derived everything else from it as
> necessary.  But the implementation cost to achieve that wish is
> turning out to be very high, so #2 (and even the philosophically
> ghastly but nicely expedient #3) are starting to look more
> attractive.
It seems to me infeasible to alter the basic behavior of time_t because 
it effects every aspect of the operating system, including the file 
system, and all the applications that rely on it, not to mention being 
non-compliant with POSIX time as it stands. It must continue to behave 
as expected, even if its not ideal where UTC is concerned. POSIX time 
and 86400-second-day systems (including Windows time) will never exactly 
match UTC at the Leap Second and we'll have to live with that partial 
inaccuracy for a long time.

But a second, parallel, time system (call it POSIX Time2) could 
implement a fixed-epoch timer (call it time2_t) and a 
Leap-Second-accurate API that would yield YMDhms representation 
including 23:59:60, call them, for examples, gmtime2() and mktime2().

With that, those applications that needed it could use the POSIX Time2 
API, and everybody else would be none the wiser. It would also define 
the mapping between legacy POSIX and the UTC-accurate POSIX Time2. 
Eventually, maybe the file system timestamps could be augmented with 
flags to mark Leap Second instances and local time parameters.

-Brooks

> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>