[ntp:hackers] ITU and Leap second elimination

Magnus Danielson magnus at rubidium.dyndns.org
Thu Oct 3 21:48:36 UTC 2013


On 10/03/2013 09:45 PM, Martin Burnicki wrote:
> John Stultz wrote:
>> On Thu, Oct 3, 2013 at 1:54 AM, juergen perlinger
>> <juergen.perlinger at t-online.de> wrote:
>> \> Could we do something that's more like evolution than revolution?
>> POSIX
>>> and other standards define a behaviour. How this behaviour is achieved
>>> is part of the implementation.  I don't see why a system should not be
>>> able to support TAI and UTC in parallel.
>>>
>>> POSIX.1-2001 specifies an API that supports more than one clock. While
>>> CLOCK_REALTIME is mandatory, other clocks can and in fact do exists,
>>> like CLOCK_MONOTONIC on Linux and BSD. Would a CLOCK_ATOMICTIME help
>>> here? The system could do the internal timekeeping in TAI, and do the
>>> necessary conversion when CLOCK_REALTIME  is requested. And
>>> CLOCK_ATOMIC
>>> would really be very similar to CLOCK_MONOTONIC. For getting the time,
>>> which is IMHO the most common operation, the conversion would be simple
>>> and I would not expect much overhead. Thinking about it, with
>>> CLOCK_MONOTONIC we might already half of the atomic time clock.
>>
>> Just FYI, with v3.10, we've added a CLOCK_TAI clockid to the Linux
>> kernel.
>>
>> Though it requires something set the timex.tai offset via adjtimex()
>> to be correct (ntpd will set it if there's a leapfile configured).
>>
>> Personally my hope is some sort of a slewed-leapsecond standard can be
>> adopted (CLOCK_UTC_SLS?), and we can consider moving CLOCK_REALTIME to
>> that (while still providing a CLOCK_UTC for those who need it).
>
> How does CLOCK_TAI increase fractions during a leap second?
>
> Wouldn't it be a good idea to let the kernel clock run on TAI, and
> convert to UTC by adding an offset when the current time is read? This
> could provide a proper mapping of UTC to TAI before, during, and after
> a leap second.
>
> PTP/IEEE1588 already uses TAI as default time base, and I could
> imagine that NTPv5 could do so optionally.
It is a much neater idea, yes. Many time-systems use TAI or TAI-like
time-scales for this very purpose, do the UTC-TAI in presentation when
needed. makes the core code much less hairy. GPS does it, so does other
systems.

Many system features in userland would also benefit from TAI rather than
UTC, such as running the POSIX clock and time_t in TAI. Log-files etc.
could just as well be in TAI.

Just don't ask the timelords about using TAI that way, they think it is
a bad idea. The whole issue about dropping leap-seconds in UTC is about
making UTC be TAI-like.

Cheers,
Magnus


More information about the hackers mailing list