[ntp:hackers] ITU and Leap second elimination

Magnus Danielson magnus at rubidium.dyndns.org
Sat Oct 5 11:16:14 UTC 2013


On 10/04/2013 08:10 PM, John Stultz wrote:
> On Fri, Oct 4, 2013 at 9:51 AM, juergen perlinger
> <juergen.perlinger at t-online.de> wrote:
>> If we really want to smear/disperse the leap second into the UTC time
>> scale, it can be done by a linear interpolation over the transition,
>> without affecting the PLL/FLL adjustments. One closed loop is enough to
>> handle. Having one that hops along happily and another one that is
>> seriously skewed sometimes sounds like a solid nightmare to me.
> True. Though the downside is such a interpolation is that it would
> have to be done in a very very hot path. So the extra conditional and
> transformation might be considered too expensive, and it could be
> cheaper to just have a separate clock who's freq diverges for whatever
> the smear-bound around the leapsecond is.
>
>> And are we sure that the leap second smear is something we really need?
>> Or is it just an artifact from an attempt to gloss over the problems the
>> current representation of UTC suffers over a radix change, aka leap
>> second? Is it still needed in the light of having CLOCK_MONOTONIC and
>> CLOCK_TAI?
> True. Until there is a standardized way to smear the leap second, I
> suspect we won't add it to Linux, but I do know other OSes are taking
> a similar approach (moving CLOCK_REALTIME to a smeared leapsecond and
> introducing CLOCK_UTC for those who need it), so I'm keeping my eye on
> it in case folks decide its the way to go.

Smearing of leap-seconds might fit some applications but not others.

time_t alongside a utctai coeff can handle leapsecs nicely.

Cheers,
Magnus


More information about the hackers mailing list