[Ntp] Antw: [EXT] Timescales

>>> Hal Murray <hmurray@megapathdsl.net> schrieb am 09.12.2020 um 11:18 in
Nachricht <20201209101830.7CB0240605C@ip-64-139-1-69.sjc.megapath.net>:
> Crazy idea dept...  But maybe...
> 
> Can we make the basic time transfer protocol use a simple/clean time scale,

> say TAI with nothing in the basic protocol about leap seconds?

Or two TAIs and two offsets?:
(TAI and current offset from UTC) (time of next offset change as TAI, next
offset)

I think the main challenge is how to represent required and optional data
items.
Once you have this pick the rest like pizza topping ;-)

> 
> The idea is to push the leap second stuff to a sub‑protocol or whereever.  
> Keep the main protocol clean.  Let the client handle leap seconds.
> 
> ("sub‑protocol" doesn't seem like a good term, but I can't think of a better

> one right now.)
> 
> If you had such a split, would you package the extras as extensions or a 
> separate mode?
> 
> Is there anything that would go in such a sub‑protocol that involves "now"? 

> For example, you might want to implement leap‑smearing by saying "the offset

> from TAI is now xxxx" but you don't need that.  The client can compute the 
> offset.
> 
> Aside from leap‑second stuff, what else would get packaged that way?
> 
> ‑‑‑‑‑‑
> 
> Given TAI, there are 2 pieces of information that a clients needs to handle

> UTC and its leap seconds.  The first is the current TAI‑UTC offset.  The 
> second is when the next leap second happens.  That data changes very 
> infrequently and with plenty of warning.  There is no need to clutter up 
> on‑the‑wire protocols with it.  A client could get it from a leap‑seconds
file 
> distributed by their distro.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 