Live data from Hacker News

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

cloudplatform.googleblog.com

71–73 of 73 posts

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

#71
post #66

Earlier quoted context omitted.

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing. Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization. I'm not even talking about bugs here—these are straight up design flaws.

There are actually two reasonable ways of handling leap seconds with gettimeofday(). The first, which is in actual use by a range of people, is to define that the kernel time is actually a TAI-10 count not a UTC count. Arthur David Olson's "right" timezone system does this. The second is to allow the microseconds count to go up to 2,000,000. * http://www.madore.org/~david/computers/unix-leap-seconds.htm...

I wonder how many clients handle that correctly. How many log files will have timestamps at "23:59:59.1500" instead of "23:59:60.500"? If you are going to break APIs you might as well make a new one instead.

And if you replace a simple API with one that requires distributing leap-second tables…

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

#72
post #66

Earlier quoted context omitted.

There are actually two reasonable ways of handling leap seconds with gettimeofday(). The first, which is in actual use by a range of people, is to define that the kernel time is actually a TAI-10 count not a UTC count. Arthur David Olson's "right" timezone system does this. The second is to allow the microseconds count to go up to 2,000,000. * http://www.madore.org/~david/computers/unix-leap-seconds.htm...

I wonder how many clients handle that correctly. How many log files will have timestamps at "23:59:59.1500" instead of "23:59:60.500"? If you are going to break APIs you might as well make a new one instead. And if you replace a simple API with one that requires distributing leap-second tables…

> And if you replace a simple API with one that requires distributing leap-second tables…

Not much worse than the distributed time zone tables we already need to update thrice a year. At least leap seconds aren't decided on by politicians.

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

#73

Earlier quoted context omitted.

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 cha…

Leap minutes could be publicized a century before being implemented, making sure all libraries accounted for the, just like leap hours.

Which then means, if you have a library that can support leap hours, why not leap seconds? More frequent small changes is much better than infrequent large changes; at the very least it will disabuse programmers of poor understanding of time and how to track it properly.
Post reply on HN