[centimeter]

Many computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html

Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there's no reason for computers to reason about the interval between events using UTC.

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

[bajsejohannes]

This is what I'd _like_ to do, but unfortunately it's not well supported. As far as I know, all OSes store the time including leap seconds, so there's no way to go back to TAI. And even if it were, that time zone is not available in user programs.

edit: Oh, I see that it's available in Linux https://www.man7.org/linux/man-pages/man3/clock_gettime.3.ht... . Can't find similar calls for Windows or OSX

[tleb_]

> The acronym TAI refers to International Atomic Time.

Good one. Wikipedia[0] is more helpful and states it comes from "temps atomique international" which is french.

[0]: https://en.wikipedia.org/wiki/International_Atomic_Time

[mdpm]

TAI is for keeping track of chronology in this gravity well of ours. UTC is for exposing this as a culturally useful value. UTC uses TAI.

[kqr]

Why is this downvoted? It sounds great to my untrained ear. You could even use TAI for user-facing timestamps (to get consistent arithmetic) and then convert to UTC only in the end before displaying the date!

[wmf]

You know in some places they will forget the conversion so you'll have weird cases that are off by 37 seconds.

[kqr]

Surely that's

a) Discovered sooner than a leap year bug, and b) Given that humans and not machines are the consumers of the UTC time, less consequential than a leap year bug.

[saurik]

That seems like it would be obvious, though, so people would fix it.

[BlackFly]

This argument naturally leads to the conclusion that you should basically never use UTC. So you use a singularity free coordinate for machine storage of times, TAI, but most users will want those displayed in their local times and nobody is using UTC. UTC is just an intermediate time, computed using leap seconds from TAI that you use on your way to a local time. But you could just remove that step.

Seems sensible to me actually. I don't really see why I would personally want to ever use UTC over TAI or local time. Sadly, a lot of time libraries don't seem to expose TAI as easily as they expose UTC, which I guess is why I continue to use UTC.