TAI is not a time zone. Timezones are a concept of civil time keeping, that is tied to the UTC time scale.
TAI is a separate time scale and it is used to define UTC.
There is now CLOCK_TAI in Linux [1], tai_clock [2] in c++ and of course several high level libraries in many languages (e.g. astropy.time in Python [3])
There are three things you want in a time scale:
* Monotonically Increasing
* Ticking with a fixed frequency, i.e. an integer multiple of the SI second
* Aligned with the solar day
Unfortunately, as always, you can only chose 2 out of the 3.
TAI is 1 + 2, atomic clocks using the caesiun standard ticking at the frequency that is the definition of the SI second forever Increasing.
Then there is UT1, which is 1 + 3 (at least as long as no major disaster happens...). It is purely the orientation of the Earth, measured with radio telescopes.
UTC is 2 + 3, defined with the help of both. It ticks the SI seconds of TAI, but leap seconds are inserted at two possible time slots per year to keep it within 1 second of UT1. The last part is under discussion to be changed to a much longer time, practically eliminating future leap seconds.
The issue then is that POSIX chose the wrong standard for numerical system clocks. And now it is pretty hard to change and it can also be argued that for performance reasons, it shouldn't be changed, as you more often need the civil time than the monotonic time.
The remaining issues are:
* On many systems, it's simple to get TAI
* Many software systems do not accept the complexity of this topic and instead just return the wrong answer using simplified assumptions, e.g. of no leap seconds in UTC
* There is no standardized way to handle the leap seconds in the Unix time stamp, so on days around the introduction of leap second, the relationship between the Unix timestamp and the actual UTC or TAI time is not clear, several versions exist and that results in uncertainty up to two seconds.
* There might be a negative leap second one day, and nothing is ready for it
> you more often need the civil time than the monotonic time
I don't think that's true? You need to time something at the system level (e.g. measure the duration of an operation, or run something at a regular interval) a lot more often than you need a user-facing time.
Thank you ; it’s kind of you to write such a thoughtful, thorough reply.
In my original comment, when I wrote timezone, I actually didn’t really mean one of many known civil timezones (because it’s not), but I meant “timezone string configuration in Linux that will then give TAI time, ie stop adjusting it with timezones, daylight savings, or leap seconds”.
I hadn’t heard of the concept of timescale.
Personally i think item (3) is worthless for computer (as opposed to human facing) timekeeping.
Your explanation is very educational, thank you.
That said, you say it’s simple to get TAI, but that’s within a programming language. What we need is a way to explicitly specify the meaning of a time (timezone but also timescale, I’m learning), and that that interpretation is stored together with the timestamp.
I still don’t understand why a TZ=TAI would be so unreasonable or hard to implement as a shorthand for this desire..
I’m thinking particularly of it being attractive for logfiles and other long term data with time info in it.
I did this for my systems a while ago. You can grab <https://imu.li/TAI.zone>, compile it with the tzdata tools, and stick it in /etc/zoneinfo. It is unfortunately unable to keep time during a leap second.
In theory, if you keep your clock set to TAI instead of UTC, you can use the /etc/zoneinfo/right timezones for civic time and make a (simpler) TAI zone file. I learned of that after I'd created the above though, and I can imagine all sorts of problems with getting the NTP daemon to do the right thing, and my use case was more TZ=TAI date, as you mentioned.
There's a contentious discussion on the time zone mailing list about adding a TAI entry. It really didn't help that DJB was the one wanting to add it and approached the issue with his customary attitude. There's a lot of interesting stuff in there though - like allegedly there's a legal requirement in Germany for their time zone to be fixed to the rotation of the earth (and so they might abandon UTC if it gives up leap seconds).
That's already false except along one line within every timezone (and that's assuming the timezone is properly set and not a convenient political or historical fiction). Let's say your timezone is perfectly positioned, and "true" in the middle. Along its east and west boundaries, local noon is 30 minutes off. Near daylight savings transitions, it's off by about an hour everywhere.
Local noon just doesn't matter that much. It especially doesn't matter to the second.
True, exactly “noon” hasn’t had a solar definition for a while. But whatever time the sun is highest for you, I imagine you still expect that to happen at the same time every day.
TAI is a separate time scale and it is used to define UTC.
There is now CLOCK_TAI in Linux [1], tai_clock [2] in c++ and of course several high level libraries in many languages (e.g. astropy.time in Python [3])
There are three things you want in a time scale: * Monotonically Increasing * Ticking with a fixed frequency, i.e. an integer multiple of the SI second * Aligned with the solar day
Unfortunately, as always, you can only chose 2 out of the 3.
TAI is 1 + 2, atomic clocks using the caesiun standard ticking at the frequency that is the definition of the SI second forever Increasing.
Then there is UT1, which is 1 + 3 (at least as long as no major disaster happens...). It is purely the orientation of the Earth, measured with radio telescopes.
UTC is 2 + 3, defined with the help of both. It ticks the SI seconds of TAI, but leap seconds are inserted at two possible time slots per year to keep it within 1 second of UT1. The last part is under discussion to be changed to a much longer time, practically eliminating future leap seconds.
The issue then is that POSIX chose the wrong standard for numerical system clocks. And now it is pretty hard to change and it can also be argued that for performance reasons, it shouldn't be changed, as you more often need the civil time than the monotonic time.
The remaining issues are:
* On many systems, it's simple to get TAI * Many software systems do not accept the complexity of this topic and instead just return the wrong answer using simplified assumptions, e.g. of no leap seconds in UTC * There is no standardized way to handle the leap seconds in the Unix time stamp, so on days around the introduction of leap second, the relationship between the Unix timestamp and the actual UTC or TAI time is not clear, several versions exist and that results in uncertainty up to two seconds. * There might be a negative leap second one day, and nothing is ready for it
[1] https://www.man7.org/linux/man-pages/man7/vdso.7.html [2] https://en.cppreference.com/w/cpp/chrono/tai_clock [3] https://docs.astropy.org/en/stable/time/index.html