[LEAPSECS] Time math libraries, UTC to TAI

[Martin Burnicki]

Steve Summit wrote:
> Martin Burnicki wrote:
>> IMO another clock type to be used with clock_gettime() would help, as
>> already proposed by Markus Kuhn (there was a link to this in a recent
>> post here), which could be used by new or actively maintained software.
> 
> Sure.  (But are you talking about CLOCK_UTC, or yet another new id?)
> At any rate, yes, ntpd is certainly a fine candidate for being
> modified to use clock_gettime and special clockids.

I have no particular ID in mind.

Generally there are 2 ways:

1.) You could leave the existing API with CLOCK_REALTIME unchanged, and
introduce a new clock ID to return "smeared" time, or ...

2.) You could change the existing API to let CLOCK_REALTIME return
"smeared" time, and introduce a new clock ID (e.g. "CLOCK_UTC") to
return "true" UTC time (whatever "true" means for timestamps taken
during a leap second).

Both approaches will probably cause unexpected behavior for certain
applications, but my feeling is that if you implement the 2nd approach
then at first the time synchronization software needs to be modified to
use the new API, while most existing applications wouldn't even notice
that CLOCK_REALTIME behaves differently, except that they don't observe
a timestep back when a leap second is inserted.

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.

Currently the TAI/UTC offset is transmitted by the PTP protocol, ntpd
passes the TAI offset to the kernel if the offset is known, e.g. from a
leap second file, or from TAI information transferred by NTP's autokey
extensions.

BTW, autokey is going to be obsoleted and replaced by the new Network
Time Security (NTS) protocol extension, so there should be a new
extension field defined for NTP to be able to transmit the TAI offset.

> (I went down the road I did because one of my secondary goals was
> to rig things up so that you could successfully use a modified --
> fully UTC-aware -- kernel along with an unmodified ntpd.  At
> first I was thinking of having the smearing scheme be adjustable
> on a per-process basis, with ntpd's process getting 'unsmeared'
> even for CLOCK_REALTIME.  But then I realized that since ntp --
> I thought -- used adjtime for everything, I could use the trick
> I described.  Oh, well.)

Yes, see my other reply to Zefram, and my thoughts on SO_TIMESTAMP and
friends.

Martin