Yes, there is a risk that systems will drift due to accumulated leap seconds without updates.
We worked throuugh the details...
but keeping time accurately and continuously (temperature extremes causing drift, power loss) is likely more of an issue in many use cases.
The background assumption here is the NASA interplanetary internet use case (and first RG before DTNRG), where a spacecraft without a clock is useless, the clock is a critical component and sync'd with updates continuously somehow, all hail the clock.
DTN doesn't scale beyond that to other use cases that well.
Lloyd Wood
Lloyd Wood
lloyd.wood@xxxxxxxxxxx
On Friday, November 8, 2019, 11:35 pm, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
Hi Magnus
I will address the other points in a later email, but on this I am concerned that WG have a misunderstanding of the timebase they are using. UNIX/POSIX time does have leap seconds it just handles them silently so you will get double increments. However since my follow-up note yesterday, I was wondering how the remote remote system knew to add a leap second in order to keep in track with the local system? Isn’t there a risk that the two systems will drift apart as leap seconds are added locally? Also there is the rollover problem to worry about.
I think the section needs to go to a specialist group for review such as TicToc/NTP to verify that it works exactly as the WG expect.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
