> Just stick with TAI and convert times to UTC when displaying them.
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.
If you want an UTC time in the distant future, more than a few years away, then you cannot know how much time will pass until then.
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.
I think you're misunderstanding the proposal. Civil time (UTC) is still known well in the future, just as well as TAI is known well in the future. It is the relationship between them that is unknown.
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.