[lifthrasiir]

I hear this argument quite a lot. But using TAI is no different from using UTC in terms of complexity because both requires the complex problem of data distribution (either of leap seconds or of UTC-TAI differences). If you ever have to use UTC somewhere you can't escape from that problem; using TAI is only moving the goalpost.

[adrian_b]

No, using TAI is simpler, because it is really the time that has passed since some origin. Therefore any operation performed with its values behaves as expected.

Neither UTC nor local times are times in the physical sense. At most you can say that they are times passed from a non-constant origin of time, which changes frequently and in an unpredictable mode for the future.

People always forget what UTC and local times really are and they very frequently make mistakes in their handling, especially for future events.

The foolproof way, as advocated by Bernstein and others, is to use only TAI for internal timekeeping and computation, and to convert to UTC or local times only the values that will be seen by human eyes.

I have done like this since many years ago, and it was always simpler for me. It would have been much simpler if this would have been a general practice, as that would have eliminated the useless conversions required for communication with other systems that use UTC, e.g. when using NTP.

[lifthrasiir]

Using TAI exclusively is simpler, but that's not the parent advocates (and neither do you, I believe).

Using TAI primarily and UTC in display has two main benefits that I consider marginal. The first is that the addition and subtraction is associative and transitive, but their use towards non-zoned wall clock timestamps like time_t is limited anyway; they normally operate on zoned date & time (e.g. "tomorrow" typically refers to the local time) or on monotonic and steady timestamps with no particular epoch. The second is that the timestamp doesn't repeat but this can also happen with TAI, just that it can only happen with (a large amount of) clock synchronization; you should be prepared of wall clock timestamps repeating no matter it's UTC or TAI.

For those reasons I consider that using TAI primarily and UTC in display is not much superior to using UTC primarily. Not that I don't wish TAI to be universal, but given the current circumstances the switch doesn't justify its cost.

[centimeter]

Using TAI is simpler because:

* Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI

* If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail

[lifthrasiir]

> Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI

Most systems don't need to keep the difference between UTC and TAI to display the UTC time anyway. TAI matters when you have to manipulate the non-zoned wall clock (as opposed to date and time components) and that's surprisingly rare.

> If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail

This is a legitimate concern, but TAI is not the solution (you should probably be using PTP or GPS clock if you do care that much) nor an essential part of the solution (any monotonic clock, including "leap smears" and UTC-SLS, will do fine). In fact I think most perceived benefits of TAI are actually of monotonic clocks and not inherent to TAI, and UTC is already monotonic... (Yes, I'm distinguishing the actual UTC and time_t; for the latter there is a relatively simple conversion to monotonic however.)

[centimeter]

Yeah, you're right that the primary benefit of TAI is that it's monotonic - but it's better to have a globally consistent monotonic schelling point than to deal with every machine having its own detached monotonic clock.

> GPS clock

GPS and TAI are essentially the same, modulo a fixed 19 second offset.