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!