That may not be suitable when you want to represent an exact point in time years into the future. You’re usually not interested in the exact number of elapsed seconds (TAI) in that case, but want to represent e.g. 2031-08-03T:00:00:00Z exactly.
The solution is to use different data types for elapsed time and for calendrical/time-of-day time. Software developers need to learn that those are not equivalent, and libraries, databases etc. need to provide appropriate data types that make the distinction clear.
The leap seconds are inserted randomly, you cannot predict when this will happen.
The UTC time is known only for the past, more precisely for the past 60 years.
For the future beyond a year, the UTC time is unknown.
On the other hand TAI, which is a real time, not a conventional quantity determined by political decisions, is known both for the past and for the future.
You are right that e.g. for scheduling meetings in the future, a different type must be used, whose meaning is "the time moment that will have this official name by then". This time should not be used for computing time differences with a resolution smaller than a day, before it becomes close enough to the present.
You cannot compute the difference between 2 UTC times, at least one of which is a future time, with resolution of a second or less.
So this does not have anything to do with TAI.
- store TAI: you'll always know how many SI seconds in the future it is, but you won't be able to accurately render UTC,
- store UTC timestamp: you'll always know what the time on the clock will be when the event happens, but you won't be able to accurately calculate how many seconds in the future it is.
The alternative is to ditch UTC. Make all wall clocks tick in SI seconds and render TAI dates in local time. This will always be correct. The only downside is you won't be able to accurately predict what position the Sun is in the sky when the event happens. But is this actually important?
So you store "the meeting is at 10am London time".
This will work, always...except for when you repeat an hour due to the DST shift but that's usually in the middle of the night on a Sunday
Some commenters seem to wonder why people care about the relationships between timescales, and how to convert between them. Well, contracts seems to be a good example. It could be vitally important to know, to the second, when a 200-year-old contract came into force.
Yes... this way leads to madness. Time seems to be in a special class of problems that is easy to get wrong and hard to get right. I think we just have to aim for "least wrong" and try to keep our sanity intact.
if you want the future time stamp to be “exactly x seconds” in the future you can store a tuple of the TAI time stamp of when you create the data point, and the SI seconds into the future from that time and then render it as appropriate for the audience’s level of understanding
And if you want the future time stamp to be not actually a time stamp but a time of day on a calendar date, then you store a tuple of the TAI creation time, the UTC date you want it to be in the future
Because you can never ever be sure of the future, by keeping the time you make the assumptions you can at least either calculate the correct answer or fix the data later when you find out something has changed.
TAI is for timekeeping.
UTC is for calendars.
In any case, while the POSIX and C standards need to accommodate atomic time, that's not enough. The software on top needs to switch to atomic timestamps too.
The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.
Well, when you explicitly throw ABI backwards compatibility out the window it's far easier to make that claim.
The main issue is that they are not restricted to that. They went overboard and basically made alloca() part of the language, causing all kinds of bugs when a newbie (or a senior, too) mistakenly uses variables instead of defines for an array size.
If they were just an annotation, it would not have been complaining, even though they would still remain quite unusable in practice due to C++ not supporting them (that's why they're seldom used in public headers).