Time scales: UTC, TAI, UT1

I'm not a time lord (an expert on time), but here is my understanding of three time systems and how they relate.

There are three properties that you _want_ from a time system, but you can only get _two_ of them; one must always be sacrificed. Each of these time systems sacrifices a different one of the properties.

Properties:

Fixed relationship with the sun / the rotation of the Earth.

Fixed relationship with SI time units - seconds. Defined in terms of... atomic things I don't understand. Wikipedia says it's defined in terms of the "unperturbed ground-state hyperfine transition frequency of the caesium 133 atom"

Fixed number of seconds per day (preferably 86400).

Here are the time systems:

UTC: Uses SI seconds, defined by atomic clocks. Corrects drift to maintain alignment with the rotation of the Earth (within fixed error bounds, a little less than +/- 1 second). Sacrifice: Variable number of seconds per day (due to leap-seconds).

TAI: Uses SI seconds, defined by atomic clocks. Exactly 86400 SI seconds per day, every day. Sacrifice: Gradually drifts so 12:00:00 moves away from _solar noon_. It's about 37 seconds of drift so far.

UT1: Exactly 86400 (UT1) seconds per day, every day. No drift - noon is solar noon. Sacrifice: UT1 seconds are not SI seconds, or even a fixed multiple of SI seconds.

Which should you use?

Well, that depends what you're doing of course!

Most people use UTC, or claim to use UTC. However, UTC is tricky if you're representing a point in time some few years in the future, because you don't know what leap-seconds will be inserted between now and then. That means _you can't compute the duration in seconds between now and then(!)_. You can compute the duration in _days_, or in _days_ + _seconds_, but note that a "day" in UTC is not a fixed length of time. You cannot accurately compute the duration _in SI seconds_ between two UTC times across two different years, unless you have accurate information about the leap-seconds between them.

Maybe that's fine and doesn't matter because you don't need to compute any such durations. That's ok. Note that if you're representing your UTC values with timestamps (ie... a count of seconds), then (a) that count is not actually an accurate count because it doesn't include leap-seconds, and (b) you cannot _represent_ leap-seconds with such a timestamp. The common way in Unix to represent leap-seconds is to have a timestamp that is split into seconds + sub-second-fractions (commonly nanoseconds but could be some other unit), and to allow the sub-second part to _itself_ be up to (not including) _2 seconds_ long. This allows you to represent a leap-second by using a sub-second value > 1 second, while still allowing conversion of the 'seconds' part to/from a calendar date+time structure. Note that the only way this works is by supporting a representation in which the calendar calculations do not rely on days all being the same length of time. You could also use a representation of (days since epoch) + (seconds), where seconds can go up to 86401 to support leap-seconds.

Anyway, another possibility is that... maybe you want 'easy' calculations that support future dates, and you want (date+time) formatted points to be _close_ to UTC? But you perhaps don't actually care about whether you're counting exact SI seconds or just... something quite close to that. In that case... congratulations! You might actually want to use UT1! For the mere cost of going back to a traditional "1 second = 1/86400th of a day" definition, instead of a super precise, stable, phyiscally supported, atomic clock SI definition, you can get both easy date calculations _and_ avoid 'noon' drifting away from 12:00:00.

Makes you think!