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

51–60 of 73 posts

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

#51

Post by m45t3r »

tyldum wrote: post #30
ac29 wrote: post #8

Earlier quoted context omitted.

>Linux timekeeping (which currently handles leap seconds via a 61-second minute instead) Google doesn't think so: "No commonly used operating system is able to handle a minute with 61 seconds"

One of the big problems is application support. How many will break by seeing 60 as current second as opposed to 59 twice?

I am sure tons of applications that use gettimeofday() to keep track of time can break in subtle ways when seeing 59 twice. Of course, they're broken considering that there is clock_gettime(), however this is a POSIX interface that is not really monotonic too by default, and the monotonic versions of it are Linux-only implementations.

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

#52

Post by leni536 »

leni536 wrote: post #40
paulajohnson wrote: post #37

Earlier quoted context omitted.

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].

Looks like I was wrong:

https://www.eecis.udel.edu/~mills/leap.html

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

#53

Post by acqq »

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

I don't see any possibility for problems, as long as you just do what has sense to do.

https://developers.google.com/time/

"We recommend that you don’t configure Google Public NTP together with non-leap-smearing NTP servers."

If you point your NTP clients to time1.google.com to time4.google.com then don't point them to anything else.

That's all.

If you use Google's time servers you are using them either to be fully in sync with Google or because you like the time-smearing feature. In both cases, just use them, don't mix. Think it as a non-standard-service which is for convenience API compatible with the "standard" NTP.

As magicalist pointed, there are already other smearing algorithms online:

https://developers.google.com/time/smear#othersmears

and Google plans to switch to the new algorithm soon. If all those who need smear standardize around one algorithm, it's going to be even better: there will be one more standard, with the new name, but then it will be even more obvious to everybody what's going on. Obviously both approaches are needed, depending on the usage scenario.

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

#54

Post by tankenmate »

ryanobjc wrote: post #24
toast0 wrote: post #20

Earlier quoted context omitted.

I think taking this step unilaterally is the only way it's going to be taken. Given that Google doesn't want to deal with leap seconds [1], and that the standards organizations have been debating removing leap seconds for years, at least they're publicizing what they're doing. [1] for good reasons

It isn't even so simple as "work with others" - the other people involved here aren't even thinking at this level. Leap seconds are an ugly hack that were inserted without any thought as to the impact on computer systems. We should not use them, they exist as a vanity project imo. Remember when leap seconds caused ALL JVMs to lock up until restarted? Or kernel bugs? ick!

In effect leap time has been used since the middle on the first millennium BC, the Babylonians discovered the difference between mean solar time and sidereal time and had corrected clocks ever since then. In order to reconcile relative earth surface time with earth mean solar time meant that time had to be inserted or removed somewhere.

In the spirit of DevOps small frequent changes are better than big infrequent changes we have leap seconds instead of leap minutes, hours, days etc. In this way noon is still when the sun is at it's highest (+/- 0.5 relative earth surface seconds).

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

#55

Post by Unklejoe »

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.

At least the IEEE 1588-2008 (PTPv2) protocol uses TAI time (with the POSIX epoch). The current UTC offset is then passed in the Announce messages (as well as some flags for indicating an upcoming leapsecond) which allows the slave to derive UTC if it wants to.

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

#56

Post by antoncohen »

For people talking about Google unilaterally doing this, it has been common to smear the leap second for the last couple years. Usually companies do it internally by having their NTP servers skew time, either with Chrony or `ntpd -x`. Standards bodies have not been able to react quickly enough to the need to smear the leap second in a consistent way. I'm thankful that Google has decided to run public NTP servers with consistently smeared leap seconds.

Here are two Red Hat articles on how to deal with the leap second, from 2016 and 2015:

https://access.redhat.com/articles/15145

http://developers.redhat.com/blog/2015/06/01/five-different-...

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

#57

Post by etatoby »

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

There's good reason it's in the standard. Many applications of computer science rely on being able to accurately measure time.

Having every second increased by a non-trivial amount (~0.001%) on some days, and not on others, will produce subtly wrong results in all kinds of fields, from manufacturing to astronomy.

This was a bad, bad choice by Google.

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

#58

Post by agwa »

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

That's an Internet-Draft, which is a work-in-progress of the IETF. It's not a formal specification. https://www.ietf.org/id-info/

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

#59

Post by toast0 »

TheGrumpyBrit wrote: post #28
brandmeyer wrote: post #5

Earlier quoted context omitted.

That doesn't make it any less unilateral. IMO, it makes it rather worse to have been doing this for five years. The situation would be much better if they had been working to build a broader consensus over all that time. As near as I can tell, they don't even have consensus within Linux, let alone POSIX or the ITU.

In the absense of a published and agreed standard, every approach is unilateral. My company is taking a similar approach - disconnecting from external NTP servers on 31st December, stepping the change in gradually, and reconnecting when we're "right" again. Google have never been in the NTP business - there's no reason for them to have worked towards a concensus on this. But when a company their size makes their appr…

Google is in the NTP business. Chromebooks sync time from their servers, android devices can (but also from carrier provide time signals), and for hosts in their cloud services.

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

#60

Post by JoshTriplett »

m45t3r wrote: post #51
tyldum wrote: post #30

Earlier quoted context omitted.

One of the big problems is application support. How many will break by seeing 60 as current second as opposed to 59 twice?

I am sure tons of applications that use gettimeofday() to keep track of time can break in subtle ways when seeing 59 twice. Of course, they're broken considering that there is clock_gettime(), however this is a POSIX interface that is not really monotonic too by default, and the monotonic versions of it are Linux-only implementations.

> I am sure tons of applications that use gettimeofday() to keep track of time can break in subtle ways when seeing 59 twice.

gettimeofday doesn't return hour/minute/second divisions; it just returns seconds/microseconds since the epoch. Functions like strftime and gmtime handle the components of time. And leap seconds don't make applications see 59 twice; they make them see 60 once (58, 59, 60, 0, 1, ...).

Quoting the manpages for gmtime and strftime:

> tm_sec The number of seconds after the minute, normally in the range 0 to 59, but can be up to 60 to allow for leap seconds.

> %S The second as a decimal number (range 00 to 60). (The range is up to 60 to allow for occasional leap seconds.) (Calculated from tm_sec.)

Post reply on HN