[ntp:hackers] ITU and Leap second elimination
john.stultz at linaro.org
Thu Oct 3 21:36:49 UTC 2013
On Thu, Oct 3, 2013 at 12:45 PM, Martin Burnicki
<martin.burnicki at meinberg.de> wrote:
> How does CLOCK_TAI increase fractions during a leap second?
Hrm. Not sure I understand the qeustion?
CLOCK_TAI is basically designed as CLOCK_REALTIME(UTC) + tai_offset.
So the usec/nsec portion of a timeval/timespec should be identical.
> 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.
Yea, so ideally I think time should be constructed as:
CLOCK_MONOTONIC: Zeroed at boot.
CLOCK_TAI = CLOCK_MONOTONIC + tai_mon_offset
CLOCK_REALTIME(UTC) = CLOCK_TAI - tai_utc_offset
Just beacuse its simpler to explain.
But due to performance concerns (CLOCK_REALTIME is what applications
hammer the most), in Linux we actually structure it as:
CLOCK_REALTIME: Initialized at boot from RTC
CLOCK_MONOTONIC: CLOCK_REALTIME - wall_to_monotonic
CLOCK_TAI: CLOCK_REALTIME + tai_offset
Where wall_to_monotonic is set to the negative of what we initialize
time as (and then adjusted any time do_settimeofday is called).
But really its the same result either way.
Though we may yet move the kernel internally to something closer to
the ideal above (since in-kernel users tend to be mostly
CLOCK_MONOTONIC based), and then precalculate the TAI - tai_utc_offset
subtraction just for userspace.
Though, if I misunderstood you and you're instead proposing the kernel
keep and only export CLOCK_TAI, and leave leapsecond processing
completely to userland (much as timezones/daylight savings is handled)
I'd agree that that would make sense, but unfortunately its not a
viable possibility given we have to support existing applications.
More information about the hackers