[dudus]

Distributed alogrithms often depend on precise clocks to maintain consistency. See google spanner for instance.

Updating the clock one second means taking a whole cluster offline untill you are sure the clocks are synchronized exactly before bringing them online again. It brings an outage and potential of headaches.

If the clocks are not synchronized you break the consensus, might cause transactions to commit partially or cause inconsistent reads and writes.

[centimeter]

Those algorithms should be using TAI, not UTC.

Any distributed system that breaks in the presence of leap seconds is necessarily poorly designed.

The fact that any non-UI code uses any time standard except TAI is a very unfortunate historical mistake that will hopefully be cleaned up over the next few years.

Thankfully since 2013, Linux kernel has supported TAI.

[beagle3]

> The fact that any non-UI code uses any time standard except TAI is a very unfortunate historical mistake that will hopefully be cleaned up over the next few years.

Unfortunately, almost everything is UI code in some way, so this won't be cleaned up.

The problem with TAI is that you cannot convert a future time to UTC if it is farther than 6 months or so in the future (because leap seconds have not been decided), so unless it never needs any conversion to/from UTC, you can't use it. (are logs UI? is crontab UI? eventually everything is)

Furthermore, you can't build an embedded no-need-to-update-every-6-month system with available common protocol - you would need to continuously feed it the list of leap-seconds, for which AFAIK there is no widely deployed protocol.

But if you use UTC, there are many protocols (TIME, NTP, SNTP, PTP), at least one of which you'll use anyway because of clock drifts, that will let you keep working.

[lifthrasiir]

> The problem with TAI is that you cannot convert a future time to UTC if it is farther than 6 months or so in the future [...]

Centimeter's argument is that such time should not be converted to TAI in advance, much like the local time for the future point (since the local time zone offset may change). All points on this also apply to the local time, e.g. it's already true that non-updatable embedded systems can't reliably do the local time calculation.

[beagle3]

They can’t do local time, but they can do UTC (and do it) without much investment if you run an NTP client. (Have 500 or so such units deployed, SNTP was giving too much trouble, switched to chrony at some point and those units require much less support)

[lifthrasiir]

> Thankfully since 2013, Linux kernel has supported TAI.

Only with the correct ntpd configuration [1]. For that reason it is impossible to rely on that API in end-user libraries.

[1] https://superuser.com/questions/1156693/is-there-a-way-of-ge...

[thayne]

And from what I can tell it doesn't work with systemd-timesyncd, which many linux systems are using now.

[brandmeyer]

Pretty sure the Spanner case isn't using either one. Google's systems futz with the speed of time near the leap second to distribute it across a wide span about midnight, UTC.

https://developers.google.com/time/smear