[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)