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

>>> Magnus Danielson <magnus@rubidium.se> schrieb am 10.12.2020 um 20:07 in
Nachricht <0bcd7806-acf1-f6a7-e779-5392772fb30d@rubidium.se>:
> Ulrich,
> 
> On 2020-12-10 07:59, Ulrich Windl wrote:
>>>>> Miroslav Lichvar <mlichvar@redhat.com> 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

Actually no: if the T is in the past it's equivalent to "no leap event
scheduled" (and vice versa).

> 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.

The only disadvantage I see is that T seeds some extra bytes.

Regards,
Ulrich

> 
> Cheers,
> Magnus
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 