We all learn as children that there are 60 seconds in a minute, 60 minutes in an hour, 24 hours in a day, and 365 days in a year.

Then things get more complicated. There are more like 365.25 days in a year, hence leap years. Except that’s quite right either. It’s more like 365.242 days in a year, which is why years divisible by 100 do not have leap years unless they’re also divisible by 400. So even though 2000 was a leap year, 2100 will not be.

The ratio of the time it takes Earth to circle the sun to the time it takes it to rotate on its axis is not an integer, and not even a nice fraction. Why should it be? It’s convenient that the ratio is approximately 365 ¼, and that’s good enough for many purposes, but that’s not the full story. And not only is the ratio not a nice fraction, it’s not even constant!

The earth’s rotation is slowing imperceptibly. Atomic clocks made is possible to measure how much it’s slowing down, but also make it *necessary* to measure. Now that atomic time is widely used, say to synchronize computer networks, the discrepancy between atomic time and astronomical observation matters.

Leap seconds have been inserted into the year occasionally to keep atomic time in sync with time relative to Earth’s rotation. These cannot be inserted on a regular basis like leap days because the change in Earth’s rotation is not regular. So committees have to decide how and when to insert leap seconds, and the process can be surprisingly acrimonious.

## Unix time

It is often said that Unix time is the number of seconds since the “Epoch,” midnight of January 1, 1970. But it’s not that simple because leap seconds are not included.

Suppose you were in London a few weeks ago. If you were sitting at a Linux command prompt to ring in the New Year and typed

date +%s

at the stroke of midnight, the result would have been 1577836800. This number factors as

1577836800 = 60 × 60 × 24 × (365 × 50 + 12)

corresponding to the number of seconds in a day times the number of days since New Year’s Day 1970, including 12 leap days. However, if a device with an atomic clock beeped once per second since the Epoch, it would beep for the 1577836827th time as 2020 began because there have been 27 leap seconds since then.

## International Atomic Time

If you don’t want to deal with Daylight Saving Time, you can use Universal Coordinated Time (UTC) [1]. If you want to go a step further and not deal with leap seconds, then International Atomic Time (TAI) is for you [2].

With TAI, every day has exactly 86,400 seconds by definition. When that many seconds pass, it’s a new day. Makes things very simple, as long as you don’t have to make reference to UTC, which tries to accommodate Earth’s rotation.

At the moment, TAI is 37 seconds ahead of UTC. There have been 27 leap seconds since leap seconds were first instituted, and TAI started out 10 seconds ahead. The next time we add a leap second [3], TAI will be ahead by 38 seconds.

## More posts on time

[1] Why is this not UCT? Because the French wanted to call it TUC for temps universel coordonné. The compromise was UTC, which doesn’t make sense in English or French.

[2] The French won this battle: TAI stands for temps atomique international.

[3] There are proposals to stop adding leap seconds, though the issue has been contentious. Maybe we won’t add any more leap seconds. Or maybe we’ll let them accumulate and add them all in at once, analogous to when several days were removed when converting from the Julian calendar to the Gregorian calendar.

when you start working with programming structures that reflect precise time units, you realize about this fancy mess

I understand that a year roughly speaking is the time it takes the earth to go around the sun, except that it doesn’t quite return to its starting place and that in fact each orbit of the earth does not quite retrace its path. So neither the sidereal year nor the tropical year is truly, truly precise. However, the earth’s orbit is more elliptical than circular, and even if the orbit doesn’t exactly retrace its path around the sun (ignoring the sun’s own motion in the cosmos), there are still two instants which are pretty well defined: the solstices. So why isn’t the year defined as the time it takes from one winter solstice (for Northern Hemisphere, e.g.) to the next winter solstice?

I recommend looking at a thread on LEAPSECS list to see deeper into what contemporary sources say about UTC and TAI origins

https://pairlist6.pair.net/pipermail/leapsecs/2020-February/007201.html

Thanks. That’s the link I included in the post.

This great C++ library might be interesting for you

https://howardhinnant.github.io/date/tz.html

BTW, the photo shows the World Clock at Berlin’s Alexanderplatz. https://en.wikipedia.org/wiki/World_Clock_(Alexanderplatz)

I don’t understand why the UTC second needs to be tied exactly to the TAI second. Define a tick to be 210 cycles of the frequency of photon absorption by transitions between the two hyperfine ground states of caesium-133 atoms, or about 22.84438 nanoseconds. The TAI second can then be defined as 43774437 ticks = 9192631770 cycles, while the UTC second can be defined as 43774438 ticks, i.e. one more tick. This extra tick would lengthen each day by 22.84438*86400 = 1973754 ns or about 2 ms.

This would have the same effect as 1 leap second every 437.74438 days, but without its disruption.

The difference amounts to 83 seconds. That is, if UTC seconds continue to equal TAI seconds as currently envisaged, by 2135 UTC will be 83 seconds ahead of where it would be with my proposal of an extra tick per second.

Now TAI might not have advanced 83 seconds ahead of UT1 by 2135. If that’s to be expected then a tick could be defined as a smaller divisor of 9192631770 such as 105, 126, 141, or 147; for example 147 cycles in a tick would have the same effect as 1 leap second every 625.3491 days. The proposal of no leap seconds between 2035 and 2135 would allow UTC to drift further from UT1 than any of these choices.

The criterion for whether to use TAI or UTC seconds in any given application could be something as simple as whether the periods of interest are shorter than a second (for TAI) or longer than a year (for UTC). Periods in between these two limits can use either as appropriate. In practical applications it is unusual to encounter a range of periods that includes both subsecond periods and multiyear periods, but those cases always have the option of using TAI seconds.