Google's New Public NTP Servers Provide Smeared Time (googleblog.com)

Google says it has built support for the leap second into the time servers that regulate all Google services. An anonymous reader shares a blogpost by Google:No commonly used operating system is able to handle a minute with 61 seconds, and trying to special-case the leap second has caused many problems in the past. 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. For timekeeping purposes, December 31 will seem like any other day. All Google services, including all APIs, will be synchronized on smeared time, as described above. You'll also get smeared time for virtual machines on Compute Engine if you follow our recommended settings. You can use non-Google NTP servers if you don't want your instances to use the leap smear, but don't mix smearing and non-smearing time servers.

Comments

Does this mean....

[The-Ixian]

Does this mean that my DPS will be slightly higher on December 31st?

Re:Does this mean....

[Diss Champ]

That depends largly on whether you play better or worse while drunk. The NTP server tweak will be a secondary effect at best.

Re:Does this mean....

[Anonymous Coward]

Does this mean that my DPS will be slightly higher on December 31st?

No. It means you'll lose a second of uptime.

Not new, just a holiday reminder PSA

[Anonymous Coward]

Google has been smearing leap seconds over NTP since 2011. This is a public reminder that Google NTP will be serving smear seconds because there is one coming.

Sounds like a part of the Star Trek:DTI Manual

[wiredog]

"don't mix smearing and non-smearing time servers"

Some examples of smeared time

[squiggleslash]

At 4.37 it'll report that 4.38 molests goats. 4.38 will retaliate by claiming 4.37 killed a man and lied about it. 4.39 will accuse 4.38 of secretly having two wives who know nothing about one another. 4.40 will claim 4.38 and 4.37 are having a secret affair and are making up allegations about one another to hide the fact. 4.41 will claim 4.40 is a multiple felon. 4.42 will accuse 4.41 of cheating on his taxes...

Re:Some examples of smeared time

[Ashtead]

And meanwhile 4:20 enjoys a joint off to the side.

Re:Falsehoods Developers Believe About Time

[heypete]

Because that's how they did it before and they consider it "safer" in the context of not making uneccessary changes this soon to the leap second. In the future they plan to do it 24 hours in advance:

Although we decided it would be safest for Google's infrastructure to handle the 2016 leap second using a 20-hour smear, the same way we handled the leap seconds in 2012 and 2015, this is not the only smear that works well. Many organizations use smeared clocks, and it would be helpful if the smears were the same. After all, the purpose of clocks is to read the same time in different places.

We would like to propose to the community, as the best practice for leap seconds in the future, a 24-hour linear smear from noon to noon UTC. We plan to use this smear starting from leap second #38, which is likely to be in 2018.

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

Well actually...

[watermark]

*pushes glasses up* *straightens pocket protector*

Actually, they would need to run the clocks 0.0013889% slower. If ran the clocks 0.0014% percent slower, they would gain 1.008 seconds instead of just 1 second even.

Hire me Google. I'll save the internets for you.

Tired of this shit.

[LTIfox]

Can we just move to TAI and convert to UTC only when interfacing the meatspace?

Re:Tired of this shit.

[LTIfox]

I mean, we have timezone stuff already - just bury those seconds in those tables. Run machine clock at TAI and calculate "local time" by adding, for example, 8hrs35seconds to whatever local timekeep says.

Re:Tired of this shit.

[TheRaven64]

Given that Terrestrial Time exists for astronomers, and the only people for whom leap seconds are useful are astronomers, can we just stop putting leap seconds into UTC?

Re:Tired of this shit.

[Xylantiel]

The problem is not so much with UTC but with unix time, as POSIX and NTP have conflicting conventions for handling leap seconds. Well and Google NTP has yet another convention. But the spirit of what you say is correct, we should probably abandon unix time as the fundamental representation on computers in favor of TAI. Software already has to consult a timezone database to convert to local time anyway, why not also require that for conversion to UTC too (to get the leap second offset from TAI).

Re:Tired of this shit.

[tricorn]

There are mods to ntpd and the time conversion libraries that do this. System clock is in real seconds since epoch, you only need to worry about leap seconds when converting between system clock and display (wall) time, which also handles time zones and leap years and everything else weird. Anyone who is dividing by 86400 to convert system clock to years, days, hours, minutes, seconds is doing it wrong. You can still divide by 86400 (or 3600 or 60) to display roughly how many hours, minutes or days a particular interval was, of course.

NTP could support this, or an auxiliary protocol defined, to distribute time conversion table changes (so with leap seconds as well as legal changes to daylight savings or other time zone changes), and to update the current difference between TAI and UTC. This would be useful even if we end up dropping DST or leap second adjustments.

Currently TAI and UTC differ by 36 seconds. For "current time", simply having that value available is sufficient for most applications that don't store the system clock value, and any that do are most likely already using a proper time conversion library.

Simply adding the ability to retrieve the clock as either "unix time (UTC-based)" or "elapsed time (TAI-based)" and convert between the two and use either as input to the time conversion routines would make it simple to update existing programs and databases. At the same time, converting once and for all to a 64-bit signed time value for seconds would help immensely with the next big time-handling crisis in about 21 years.

I fear that Google is just papering over the problem and making things more difficult to properly solve.

Re:O cursÃd spite

[Bruce Perens]

Geez, foiled by Slashdot's non-UTF8-ness again.

Re:Hey look the flow rate is a little high.

[MightyYar]

Just make the stocks trade in time-coordinated batches. The batches can still be relatively fast - even every second - just so it is slow enough to stop the stupid games with the speed of communications.

Re:It's not that easy

[Xylantiel]

It's funny to me that they say the Earth's rotation is "determined" by IERS. No, it is *measured*. A subtle implied difference, but a critical one. The problem here is actually with unix time, not UTC. TAI as an alternative to unix time actually makes pretty decent sense. When was the last time you manually converted from seconds since epoch to day/month/year?

I think the point is that since time zones are actually updated more frequently for political purposes than leap seconds occur, it makes sense, for network-connected computers at least, to just stuff the leap seconds in the same distribution channels (already done actually) and abandon trying to hack around the clumsy (non-monotonically increasing) definition of unix time.

Re:Hey look the flow rate is a little high.

[BronsCon]

This.

Every trade that occurs within a given interval (I think 1 second is too short still, maybe a minute... or 1/4 hour, since that's often how long quotes are delayed for the average trader) trades at the same price for a given transaction type. The net effect on the market would be the same, we just wouldn't have, for example, two people placing SELL orders for a million shares of something at $100/share and one of them getting $190/share while the other only gets $10/share, which does currently happen.