[LEAPSECS] Time math libraries, UTC to TAI

[Stephen Scott]

Hello Steve;

Your computer must have a clock time error or teh network is extremely, 
extremely slow.
The message timestamped 2017-01-04 20:39 was received at about 
2017-01-05 16:57-05:00

-Stephen


On 2017-01-04 20:39, 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.
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus