5 ms·

A fun, related read on what Google does when they must introduce a leap second to their fleet of servers: http://googleblog.blogspot.com/2011/09/time-technology

by bryanh 12y ago

A fun, related read on what Google does when they must introduce a leap second to their fleet of servers: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...

anon4 12y ago
Interesting that they don't keep them in TAI. I would expect having the hw clock of the PC be in TAI to be the most pain-free option. Or is that not possible?
- lmm 12y ago
  There's very little OS- or application-level support for it. Adding support would probably take more effort than convincing governments to abolish leap seconds.
  - edwintorok 12y ago
    The "broadcast time" (and NTP time) doesn't need to have leap seconds at all, you could consider UTC as a timezone too. You already need a table to convert between UTC and localtime, so why not use a table to convert between machine time and UTC too? http://www.ucolick.org/~sla/leapsecs/right+gps.html http://www.ucolick.org/~sla/leapsecs/right+gps.html
  - gpvos 12y ago
    Abolishing leap seconds is a terrible option. In a few thousand years' time, official time will have shifted noticeably from solar time, which is not acceptable to society. It's just code. We should draw up a transition plan to using TAI in computers.
    - wmf 12y ago
      Time is already "wrong" by an hour or more in many places: http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-much-is-time-wrong-around-the-world/ http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-... I'd rather have no leap seconds until the accumulated error reaches 30 minutes and then modify time zone offsets (which is already done twice a year anyway).
    - giovannibajo1 12y ago
      In software engineering, batching changes is almost always good, because once you look at some code, migrate a database, profile a section, it's very convenient (economically speaking) to flush any similar task of reasonable size in the same area. Leap seconds are the opposite; they try to spread the time changes as much as possible, adding single seconds whenever possible. If they went for minutes instead of seconds, it's possible that a leap minute would be added once per century (or less); entire generations of computer scientists would not have to deal with it and Google could come and go (for good) without ever having to shift their clocks. Humans don't really care if you add a minute at midnight of new years eve, in fact, it could even be fun to countdown twice for the new year, but for computers it would be a massive saving of engineering effort.
      - gpvos 12y ago
        You have valid points there. But in that case, I think using the existing system of time zones (i.e., leap hours) may be a better idea than introducing a somewhat new mechanism of leap minutes. Also because leap seconds are accelerating, in a few thousand years' time we'd have leap minutes every month, so it's better to postpone any problems even further into the future.
- klodolph 12y ago
  This just pushes the problem somewhere else. Smoothing leap seconds gives clock skew of 500ms, requires no changes to software. Handling leap seconds correctly in UTC requires checking millions of lines of code and adding a new way to query the clock. Using TAI causes interoperability problems with other systems; there are 35 seconds between TAI and UTC, and now you have to check millions of lines of code to make sure you correct for leap seconds when you display time to the user. Ugh. Smoothing is the second-best option from a software engineering perspective. Whining about it until IERS stops using leap seconds is the first-best option, the astronomers will have to deal with it.
datenwolf 12y ago
Or, you could just run your computers wall display clock on UT1, which is effectively UTC with the leap seconds "smeared" over half a year. The deviation from the UT1 second to the UTC second is less than the precision most computer's clocks.

by bryanh 12y ago

anon4 12y ago

Interesting that they don't keep them in TAI. I would expect having the hw clock of the PC be in TAI to be the most pain-free option. Or is that not possible?

lmm 12y ago
There's very little OS- or application-level support for it. Adding support would probably take more effort than convincing governments to abolish leap seconds.
- edwintorok 12y ago
  The "broadcast time" (and NTP time) doesn't need to have leap seconds at all, you could consider UTC as a timezone too. You already need a table to convert between UTC and localtime, so why not use a table to convert between machine time and UTC too? http://www.ucolick.org/~sla/leapsecs/right+gps.html http://www.ucolick.org/~sla/leapsecs/right+gps.html
- gpvos 12y ago
  Abolishing leap seconds is a terrible option. In a few thousand years' time, official time will have shifted noticeably from solar time, which is not acceptable to society. It's just code. We should draw up a transition plan to using TAI in computers.
  - wmf 12y ago
    Time is already "wrong" by an hour or more in many places: http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-much-is-time-wrong-around-the-world/ http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-... I'd rather have no leap seconds until the accumulated error reaches 30 minutes and then modify time zone offsets (which is already done twice a year anyway).
  - giovannibajo1 12y ago
    In software engineering, batching changes is almost always good, because once you look at some code, migrate a database, profile a section, it's very convenient (economically speaking) to flush any similar task of reasonable size in the same area. Leap seconds are the opposite; they try to spread the time changes as much as possible, adding single seconds whenever possible. If they went for minutes instead of seconds, it's possible that a leap minute would be added once per century (or less); entire generations of computer scientists would not have to deal with it and Google could come and go (for good) without ever having to shift their clocks. Humans don't really care if you add a minute at midnight of new years eve, in fact, it could even be fun to countdown twice for the new year, but for computers it would be a massive saving of engineering effort.
    - gpvos 12y ago
      You have valid points there. But in that case, I think using the existing system of time zones (i.e., leap hours) may be a better idea than introducing a somewhat new mechanism of leap minutes. Also because leap seconds are accelerating, in a few thousand years' time we'd have leap minutes every month, so it's better to postpone any problems even further into the future.
klodolph 12y ago
This just pushes the problem somewhere else. Smoothing leap seconds gives clock skew of 500ms, requires no changes to software. Handling leap seconds correctly in UTC requires checking millions of lines of code and adding a new way to query the clock. Using TAI causes interoperability problems with other systems; there are 35 seconds between TAI and UTC, and now you have to check millions of lines of code to make sure you correct for leap seconds when you display time to the user. Ugh. Smoothing is the second-best option from a software engineering perspective. Whining about it until IERS stops using leap seconds is the first-best option, the astronomers will have to deal with it.

datenwolf 12y ago

Or, you could just run your computers wall display clock on UT1, which is effectively UTC with the leap seconds "smeared" over half a year. The deviation from the UT1 second to the UTC second is less than the precision most computer's clocks.