In order for CLOCK_TAI to function properly, a program (usually ntpd) has to use the adjtimex family of system calls in order to tell the kernel what the difference is between TAI and UTC. ntpd will do this as long as it has been configured with a leap seconds file.

Unfortunately, although the majority of distributions ship with a leap second file from the zoneinfo database, many or most of them (I have Arch here) do not configure ntpd to know about it, so ntpd does not set things up properly for CLOCK_TAI to work. Calling clock_gettime(CLOCK_TAI, ...) produces the same result as clock_gettime(CLOCK_REALTIME, ...), yielding UTC instead of the requested TAI.

The result is that CLOCK_TAI, which one would usually wish to use to improve the correctness of a program’s date and time handling, produces utterly incorrect behaviours on the vast majority of boxes, unless the system administrator is conscientious enough to configure.

I would like to suggest that clock_gettime(CLOCK_TAI, ...) and friends should return an error (EINVAL? ENOTSUP?) when it would return the same as CLOCK_REALTIME, so that programs can detect when it’s not been set up correctly and either tell users to go and set up their leap second data file properly, or try to improvise TAI on top of UTC using  (at the cost of not being able to be accurate during leap seconds themselves), or both.

A workaround for programs which want to detect when CLOCK_TAI is wrong is to try to detect when it hasn't been set up properly by getting both CLOCK_TAI and CLOCK_REALTIME and falling back to trying to emulate TAI on top of time_t when the difference between the tv_sec value is ≤ 1 second (not = 0, because it could happen that the first clock was checked at .00001 seconds before a whole second and the latter one at .00001 seconds after the whole second). But even that has edge cases — putting similar logic in the kernel could make it work correctly all the time.