undefined | Better HN

0 pointspaulajohnson9y ago0 comments

I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be doing this on public-facing NTP.

0 comments

klodolph9y ago

Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two.

It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of just how deeply broken the status quo is?

creshal9y ago

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

klodolph9y ago

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing.

Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization.

I'm not even talking about bugs here—these are straight up design flaws.

1 more reply

toomuchtodo9y ago

> and there is no mechanism in NTP for a server to say "I'm using time-smearing".

That should most definitely be in the standard, along with communicating to the client full details about how smearing is configured.

creshal9y ago

Sure, but until then, public-facing NTP servers should stick to the current standard.

j / k navigate · click thread line to collapse

0 pointspaulajohnson9y ago0 comments

0 comments

klodolph9y ago

creshal9y ago

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

klodolph9y ago

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing.

Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization.

I'm not even talking about bugs here—these are straight up design flaws.

1 more reply

toomuchtodo9y ago

> and there is no mechanism in NTP for a server to say "I'm using time-smearing".

That should most definitely be in the standard, along with communicating to the client full details about how smearing is configured.

creshal9y ago

Sure, but until then, public-facing NTP servers should stick to the current standard.

j / k navigate · click thread line to collapse