13 ms·

I'm not sure where to find the white paper, but this blog post [2011] probably has most details as well. Its key take-aways: - their (and probably others') dis

by mrngm 3y ago

I'm not sure where to find the white paper, but this blog post [2011] probably has most details as well. Its key take-aways: - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) - repetition of one second is difficult to accommodate for, e.g. with disk writes or storage of e-mail messages - the initial leap smear was a hack/patch in their NTP servers by not setting LI (leap indicator), but modulating time within a window w before midnight: lie(t) = (1.0 - cos(pi * t / w)) / 2.0 - they tested both positive and negative leap smear on a set of 10k servers - leap smears eliminate the need for programmers to handle leap seconds [2011]: https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-... (edit: list markup)

throw0101c 3y ago
> - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) Time moves forward with both positive and negative leap seconds. With the positive ones, which we've seen before, we go from 23:59:59 to 23:59:60 to 00:00:00. Always forward. With negative ones, which have not been seen in the wild, it goes from 23:59:58 to 00:00:00, skipping :59. Also always forward.
- toast0 3y ago
  Well, the problem is most systems are on unixtime, and unixtime doesn't allow for a :60. Traditionally, :59 is repeated, so the integer seconds is still monotonic, but the fractional part repeats. This confuses many applications. And ocassionaly confuses the Linux kernel, too [1]. Other kernels may have done better. I think a negative leap second is less likely to cause the same sorts of problems. Otoh, it's never happened before, and leap seconds are generally not well tested. [1] https://www.networkworld.com/article/711440/software-linux-is-culprit-in-leap-second-lapses-cassandra-exec.html https://www.networkworld.com/article/711440/software-linux-i...
  - account42 3y ago
    Including leap seconds in unix time was a mistake - it should follow TAI instead of UTC and leave leap seconds entirely as a matter of the formatting/timezone code.
- mrngm 3y ago
  From the blog post: > Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. Not quite "always forward".

by mrngm 3y ago

throw0101c 3y ago

> - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) Time moves forward with both positive and negative leap seconds. With the positive ones, which we've seen before, we go from 23:59:59 to 23:59:60 to 00:00:00. Always forward. With negative ones, which have not been seen in the wild, it goes from 23:59:58 to 00:00:00, skipping :59. Also always forward.

toast0 3y ago
Well, the problem is most systems are on unixtime, and unixtime doesn't allow for a :60. Traditionally, :59 is repeated, so the integer seconds is still monotonic, but the fractional part repeats. This confuses many applications. And ocassionaly confuses the Linux kernel, too [1]. Other kernels may have done better. I think a negative leap second is less likely to cause the same sorts of problems. Otoh, it's never happened before, and leap seconds are generally not well tested. [1] https://www.networkworld.com/article/711440/software-linux-is-culprit-in-leap-second-lapses-cassandra-exec.html https://www.networkworld.com/article/711440/software-linux-i...
- account42 3y ago
  Including leap seconds in unix time was a mistake - it should follow TAI instead of UTC and leave leap seconds entirely as a matter of the formatting/timezone code.
mrngm 3y ago
From the blog post: > Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. Not quite "always forward".