Re: [Ntp] [EXT] NTPv5 -- drop leaps

[Martin Burnicki <[e-mail]>]

Am 24.07.23 um 03:08 schrieb Warner Losh:
> On Sun, Jul 23, 2023, 6:08 PM Steven Sommars <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Two alternate proposals instead.
> 
>     The existing leap smearing mechanism(s) has worked well enough and
>     can be used if needed in the future.  There's no need to force-fit
>     special-case signalling into NTPv5.
>     A BCP for deploying leap-smearing (and for avoiding it) would
>     benefit operators of both NTP servers and clients.  E.g., understand
>     exactly which devices will perform the smearing, ensure that all
>     utilized NTP servers use the same smearing algorithm, recognize that
>     your client's notion of current time may differ from other clients,
>     log the use of leap-smearing, and leap smearing may not be
>     compatible with FINRA and other requirements.
> 
>     The second alternative is more radical.  Smeared time defines a new
>     time scale(s); call it UTC-LS.   NTPv5 continues the current UTC
>     focus, but adds a uniform mechanism for additional time scales.
>     TAI, UT1, UTC-LS.    Leap smearing is no longer a special case.
> 
> 
> That's too restricted. What about UT1 or GPS time.

Or some arbitrary time.

> I rather like nothing and muddle. Next best is extensions to report 
> timescale and offset.
> 
> But UTC-LS is too vague. There are a dozen ways to smear

Indeed, and I don't think you can easily define a list of defined 
smearing methods.

Also, the name UTC-LS can easily be confused with UTC-SLS which a 
specific proposal was already made in 2005:
https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/

I still stand by my suggestion of allowing to send any time and a field 
with the offset to UTC so that the client can easily convert back to UTC 
if he wants.

Removing things like this from the specs, as suggested on the list here, 
does make the specs easier to read for those uninterested in the 
details. However, it also leads to many software variants doing this 
"implementation-defined", which doesn't exactly increase interoperability.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com