Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making every (leap) second count with our new public NTP servers

cloudplatform.googleblog.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Making every (leap) second count with our new public NTP servers

#31

Post by nothrabannosir »

leni536 wrote: post #23

Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.

Because leap seconds are not deterministic, kind of like time zone changes. It would make timestamp date calculations A) harder and B) need constant updates to work. Hell for firmware and embedded code.

Edit: the worst thing is: it would make those calculations harder to do correctly, but it would be too seductive to not care for leap seconds. After all, what's a few seconds error, really? This leaves you in a state where, guaranteed, 99% of time software will not be correct and the error will compound over time.

Re: Making every (leap) second count with our new public NTP servers

#32

Post by klodolph »

liotier wrote: post #29

“Leap Smearing must not be used for public-facing NTP servers” - https://tools.ietf.org/html/draft-ietf-ntp-bcp-02

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

Re: Making every (leap) second count with our new public NTP servers

#33

Post by leni536 »

detaro wrote: post #27
leni536 wrote: post #23

Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.

Google introduced this exactly to not have to deal with it client-side, while still having UTC timestamps that match the rest of the world most of the time.

You have to deal with it at client side. It doesn't make sense to fix broken software by introducing broken time servers. It could make sense to provide a wrapper library that provides smeared leap seconds and use that for broken software only (like libfaketime).

Now if I want to write software that uses precise TAI, I can't do that because of broken UTC from time servers and TAI is defined as UTC+tai_offset on my side.

Re: Making every (leap) second count with our new public NTP servers

#34

Post by paulajohnson »

klodolph wrote: post #32
liotier wrote: post #29

“Leap Smearing must not be used for public-facing NTP servers” - https://tools.ietf.org/html/draft-ietf-ntp-bcp-02

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

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.

Re: Making every (leap) second count with our new public NTP servers

#37

Post by paulajohnson »

KayEss wrote: post #12
brandmeyer wrote: post #3

> Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and “smear” the extra second across these twenty hours. Holy leaping second, batman! Unilaterally being off by up to a half second from the rest of the world's clocks is a pretty aggressive step. I think I would have preferred to see a resolution made by…

It's far better than what POSIX clocks do. They'll just drop back a second and you'll get the same time twice.

That is a historical artifact. The original Unix developers decided to treat time as seconds since the start of 1970, implicitly assuming that every day has 86400 seconds. Back then UTC was in its infancy, most programmers had not even heard of leap seconds, and most computer clocks were set by the sysadmin looking at his watch. If we were starting from scratch we would have a date-time type with a day number field and a seconds-since-midnight field. However that would be a breaking change for every piece of software out there, so we are stuck with a time_t that cannot handle leap seconds.

Re: Making every (leap) second count with our new public NTP servers

#39

Post by paulajohnson »

russdill wrote: post #25
leni536 wrote: post #23

Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.

Yup, it seems awesome, but software needs to be written to handle it properly. I think it'd work no problem with software already written against monotonic clocks, but everything else would probably need some fixing.

The problem is that time_t (seconds since 1970) implicitly assumes 86400 seconds per day. You would have to redefine time_t and rewrite every piece of code that uses it.

Re: Making every (leap) second count with our new public NTP servers

#40

Post by leni536 »

paulajohnson wrote: post #37
KayEss wrote: post #12

Earlier quoted context omitted.

It's far better than what POSIX clocks do. They'll just drop back a second and you'll get the same time twice.

That is a historical artifact. The original Unix developers decided to treat time as seconds since the start of 1970, implicitly assuming that every day has 86400 seconds. Back then UTC was in its infancy, most programmers had not even heard of leap seconds, and most computer clocks were set by the sysadmin looking at his watch. If we were starting from scratch we would have a date-time type with a day number field a…

Or we would use the NTP timestamp directly (or a lower precision version) as time_t, which (AFAIK) doesn't suffer from leap seconds. On can always convert time_t to truct tm, tm_sec is defined to be in the range of [0..60].
Post reply on HN