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
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
