Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

[Miroslav Lichvar <[e-mail]>]

On Wed, Jan 06, 2021 at 09:57:56AM +0000, FUSTE Emmanuel wrote:
> 
> I clearly don't understand the resistance to go to a linear TAI like 
> form for the core time-stamping format as long as the TAI-UTC offset is 
> part of the core protocol frame.

That offset is not always available, e.g. with a DCF77 refclock.
Relying on other sources is not always acceptable.

> You will have to do some conversions and adaptations in the OS 
> adaptation layer, as today for all NTP implementations, and this layer 
> will not be messier as the core is today. No need to wait that operating 
> systems fully support a non-leaping timescale, or TAI-UTC offset natively.

No, it will be messier. That's the other problem.

If your OS doesn't have a TAI clock or it doesn't support timestamping
with the TAI clock, you will have to resolve the ambiguity in your NTP
implementation. That will not be 100% reliable as you cannot be sure
if the timestamp is captured before or after the leap. You are only
guessing. If the client doesn't know that the server is only guessing,
it may get unexpected errors in measurements and its clock disrupted.

The best thing you can do on such an OS is to suspend the operation
around leap second, the same thing as when using a leaping timescale.
In other words, there is no advantage of using a non-leaping timescale
for the time transfer. It would only make things even more messier
than they already are.

-- 
Miroslav Lichvar