[ntp:hackers] smearing the leap second
juergen.perlinger at t-online.de
Mon Jul 27 18:54:22 UTC 2015
On 07/11/2015 10:32 AM, Hal Murray wrote:
> john.stultz at linaro.org said:
>>> No systems support TAI. There is no API to get time in TAI.
>> Linux supports CLOCK_TAI via clock_gettime(). One can also get the
>> tai_offset via adjtimex().
> Thanks for the correction. I thought I checked, but either I fat-fingered
> something or I tried it on an old-old system.
> The man page for clock_gettime() doesn't mention CLOCK_TAI, at least not on
> any of the boxes I tried. It is defined in /usr/include/linux/time.h (at
> least for recent kernels)
> Including time.h isn't good enough on many of the systems I tried. Maybe it
> would work if I defined the right magic feature symbol.
> It gives sensible results if somebody tells the kernel the TAI offset. ntpd
> does that if it has a leap file.
There are also some GPS receivers that can provide the TAI offset. Just
not in any standard NMEA sentence, but like Garmin's $PGRMF. (Well,
technically it's the offset between UTC and GPS time scale in this case,
but there's a fixed offset to TAI from there.)
Other receivers might do it, too, but my access to such hardware is
limited. Could this be something of interest for GPSD?
> If the TAI offset isn't setup, it lies rather than giving an error.
I think there's a difference between 'lying' and 'not knowing', but it
amounts to the same behaviour in the end. But enforcing a fake value
because the true/real/right value cannot be established would be another
form of lie, and refusing to operate just because the current leap era
is not known looks like a bad idea to me.
I guess we currently have the best (but still bad) choice from a number
of bad 'solutions'.
> Do you know of any distros that setup and maintain a leap file out of the box?
> I couldn't find CLOCK_TAI on NetBSD or FreeBSD.
> Getting TAI using the tai_offset via adjtimex() isn't trivial, at least if
> you expect your code to do the right thing when running over a leap second.
> You have to do something like:
> read tai_offset
> read time in UTC
> read tai_offset again
> If the tai_offsets differ, you were reading the clock close to the leap
> second. Try again.
More information about the hackers