[Ntp] Antw: Re: Resending: Thoughts on draft-ietf-ntp-refid-updates

>>> Daniel Franke <dfoxfranke@gmail.com> schrieb am 20.07.2018 um 15:47 in
Nachricht
<CAJm83bAZcxw6GuXMwJiy0dNJ7RmjJJaXeSNzwQ_5_0xCXUKH+A@mail.gmail.com>:
> On Fri, Jul 20, 2018 at 9:33 AM Martin Burnicki
> <martin.burnicki@meinberg.de> wrote:
>> Please don't blame ntpd for smearing leap seconds.
>>
>> The leap second is inserted/handled by the kernel, and that's basically
>> the way it should be.
>>
>> However, this is often done in a way that applications may become
>> confused if the system time is simply stepped back by 1 s.
>>
>> If you used any other time synchronization software which just passes a
>> leap second announcement to the kernel then the applications will have
>> the same problems.
>>
>> Leap second smearing by an NTP server is just an optional way to avoid
>> these problems because there's no better way to get around it.
> 
> In a better world, both NTP time and POSIX time would be TAI‑based,
> and leap second updates would be handled through the time zone
> facility, with UTC being just another local time zone. Alas, that ship
> sailed away a long time ago.

There may be an problem for embedded devices, however: As obviously your
proposal requires that timezone data is provided (and installed) significant
time before a leap second occurs, I see a problem with embedded devices, as
those see software updates quite infrequently (if at all).

> 
> In a slightly worse world still better than the current one, NTP would
> provide unsmeared time to the kernel, which would provide smeared time
> through the what‑ought‑to‑be‑legacy POSIX APIs, and unsmeared time
> through a new better‑designed API that expresses time as
> whole‑days‑since‑epoch + seconds‑since midnight, so that time can be
> expressed unambiguously during leap seconds. That ship, too, has
> lifted anchor, but maybe it's not too late to jump onto it.

Actually what I was thinking is: Why npt start to adjust the duration of a
second once the leap second is announced (6 months ahead)? That way no normal
system will ever notice. The disadvantage is that all refclock systems will
have to agree on it. That's quite unlikely, however, especially for GPS...

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