How Google handle leap seconds

http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

by cientifico • 14 years ago

138 28 14 years ago

googleblog.blogspot.com

harlowja• 14 years ago

Has this been contributed back to the community?

toemetoch• 14 years ago

yes, I don't know about code but it's available in the form of an article that is detailed enough to implement it in any system.

kunalmodi• 14 years ago

I hate that the header stays fixed, takes up like half the screen

crazygringo3• 14 years ago

Strange, mine condenses into a small line at the top as soon as I scroll. (Chrome on OSX)

lukeschlather• 14 years ago

Yeah, I never thought I'd see the day I'd have to view -> page style -> no style on a Google site.

DanielRibeiro• 14 years ago

Former discussion: http://news.ycombinator.com/item?id=3002009

A much longer discussion, but on different link, we had 16 days ago: http://news.ycombinator.com/item?id=4112002

agf• 14 years ago

There is a dead link in the blog entry to the Chubby paper; it's available at http://research.google.com/archive/chubby.html

crazygringo3• 14 years ago

How is handling a leap second any different from dealing with Daylight Savings Time, when a whole hour can skip or repeat itself? Wouldn't you just use the same logic?

Or is it the fact that servers tend to ignore DST, being set to GMT and using timezone+DST only for datetime rendering/parsing, like Unix timstamps? While leap seconds actually affect the clock itself?

haberman2• 14 years ago

Yep, it's the latter. Leap seconds actually affect time_t values, whereas daylight savings does not.

I think it's simpler to think of time_t (or "unix time") as independent of any time zone. It's the number of seconds since an arbitrary "epoch" that happened simultaneously everywhere in the world. It so happens that the epoch happened at midnight GMT.

Of course it's not literally the number of seconds since the epoch because of leap seconds.

ricardobeat• 14 years ago

It is literally the number of seconds because of leap seconds :)

wmf• 14 years ago

servers tend to ignore DST, being set to GMT ... While leap seconds actually affect the clock itself?

Yes.

dfc• 14 years ago

Markus Kuhn proposed something similiar:

"UTC with Smoothed Leap Seconds (UTC-SLS)": http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/

aaronsw• 14 years ago

The real solution is not to use broken NTP: http://cr.yp.to/proto/utctai.html

nas• 14 years ago

I was disappointed to read that their solution didn't involve switching to TAI. The kernel should use seconds since epoch and leap seconds should be a user space issue, just like timezones.

lallysingh• 14 years ago

This method lets you isolate the changes to this level of the stack; everything up top can make the convenient, if slightly incorrect assumptions about time.

jbyers• 14 years ago

(2011)

crazygringo3• 14 years ago

Does anyone know what the original reasoning was for Unix timestamps to not account for leap seconds? So that one timestamp can actually point to two physical times a second apart?

I mean, I know leap seconds aren't scheduled, and it's convenient to find a day by dividing by 86400, but it really seems like "physical seconds since the epoch" is the "fundamental" amount of time, as opposed to physical days, and the function that calculates datetimes (including time zones and DST) could just handle the leap seconds too.

It's obviously not changing now, was just wondering about the historical context of it. It seems like Unix time and leap seconds both come from the beginning of the 1970's... was Unix time defined before the concept of leap seconds were?

jwm• 14 years ago

From the Wikipedia article on Leap Seconds:

> Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable. Insertion of each UTC leap second is usually decided about six months in advance by the International Earth Rotation and Reference Systems Service (IERS)

I don't see how applications could make unix second <-> day conversions without downloading a map from the IERS, if leap seconds were included.

raldi2• 14 years ago

I wonder why it's a cosine-based formula, rather than linear.

anothermachine• 14 years ago

For smoothness, I presume, to avoid a sudden change in the rate of time passage at the start and end of the day.

raldi2• 14 years ago

I don't follow -- wouldn't a linear approach yield a maximally even rate of adjustment?

shalmanese• 14 years ago

Cosines are smooth at every level of differentiation.

kentonr• 14 years ago

Maybe they chose it because they wanted to "ease" in the change to prevent the machines from distrusting the time server?

nodrama• 14 years ago

It seems to me that the problem is in all kinds of code that relies on time to do some critical operation when it really should not. Time is for people.

Computers should use a separate "time", that only moves forward. A numbered pulse.

its_so_on• 14 years ago

smart. Spoiler/summary: they use a "leap smear" to keep code logic from breaking.

Instead of making code encounter the same second twice or not encounter a certain second, they smear the extra second over several hours beforehand through the central time server; by the time the leap second comes you're already sufficiently ahead/behind. (My comment: This works because the granulatiy of the time isn't that low anyway, so obviously no code can rely on it. Therefore, if code is correct without the smear it will be correct with the smear.)

brugidou• 14 years ago

Is that part of google's "TrueTime" project? I heard about it at a Google Spanner presentation. They use GPS receivers in their DCs to get an exact time.

How Google handle leap seconds

Related Stories