[ntp:hackers] smearing the leap second

juergen perlinger 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 mailing list