Re: [Ntp] Antw: [EXT] Re: Timescales

[Magnus Danielson <[e-mail]>]

Ulrich,

On 2020-12-10 07:59, Ulrich Windl wrote:
>>>> Miroslav Lichvar <[e-mail]> schrieb am 09.12.2020 um 14:46 in
> Nachricht <20201209134612.GC2352378@localhost>:
>> On Wed, Dec 09, 2020 at 02:29:32PM +0100, Ulrich Windl wrote:
>>> However you could see the leap indication flag also as "leap confirmation"
>>> flag (actually there will be a leap event). With only DCF‑77 clocks this 
>> could
>>> be a problem. As said earlier, it would be best if NTP could reliably 
>> transfer
>>> the leapsecond table, or at least the relevant part of it to make clients 
>> know
>>> in advance that and when a leap event is scheduled.
>> There is the tzdist (RFC7808) protocol designed for that.
>>
>> NTP could distribute a leap‑second table (it already did it with
>> Autokey, right?), but isn't NTP about distributing current time,
>> rather than reconstructing time in the past or future?
> Hi!
>
> You all seem to have missed my point: In the recent past there was a lot of
> discussion and confusion what the LI (Leap Indicator) means:
> Leap second today, leap second at the end of the month, leap second soon. So
> having the definite time of the next leap event would all make this easier.
> Actually it could make the LI even obsolete.

No, not really. I did see that, but there is a subtle point to it.

You have two scenarios:

1) You know the current TAI-UTC offset, and there is no know upcoming
offset.

2) You know the current TAI-UTC offset, and you know there is a upcoming
new offset introduced at Time T to become offset O.

As you provide the T and O values, you need to know if those fields is
valid or not, for that you typically use a separate flag to indicate
that, rather than put restrictions on how to interpret those values to
mean that. So, I think it is provides a much better function to have
such a flag.

Separate from that, people have suggested that a flag should indicate a
particular occurrences time. Unfortunately, that has proven the source
of nasty bugs, and also, it can put implications of for how long before
it can be announced, and you end up knowing that you know there is an
upcoming leap second, but the distribution mechanism does not allow you
to announce it yet because it would be interpreted for the wrong time.
Whenever possible, it is therefore advisable to always supply the
time-stamp at which time the future event will occur, as it then leaves
no room for misinterpretation. In the similar sense, it is advisable to
not use interpretation of the fields to know if they provide a future
event or not, but only indicate the facts about the future event which
occurrence is flagged with a dedicated bit.

Being able to compress things does not make it wise, in fact it has
turned out to be very unwise to do so, as it is not future-proof at all.

So, this is why I advocate for a flag to indicate upcoming leap-second,
a field to indicate the current TAI-UTC difference, upon the flag being
set the values of future time-stamp and new TAI-UTC offset becomes valid
fields.

Cheers,
Magnus