4 ms·
> - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) Time moves forward with both positive
by 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 agoWell, 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 agoIncluding 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 agoFrom 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".