I love the idea of switching to atomic time. Using a different paradigm to conceptualize it could lead all sorts of whimsical new approaches to representing it, and where whimsy wanders new insights and discoveries often ensue.
However, most civilian applications want a time that is synchronized, to bounded degree, to the Earth's rotation. UTC has leap seconds, which are occasionally added or removed, to make that happen.
There's been a push for removing leap seconds from UTC, because that'd be convenient for computers. But no one's figured out how to change the Earth's speed to match this new definition of UTC :-). So if we want time-of-day to be related to the position of the sun in the sky, adjustments like leap seconds are necessary.
The biggest reason to describe it as "switching from UTC to TAI" (at least for me) is due to Unix time. Unix time is an elegant concept at first glance, ideally it's a free-running, monotonic counter that abstracts us away from timezone problems, an unambiguous representation of time. You only adjust the timezone settings or the timezone database, the time itself is never adjusted.
Unfortunately, using UTC rather than TAI as Unix time's foundation is a fatal mistake. As Unix time cannot represent leap seconds, all the previous advantages break down - we had to freeze or advance the Unix time itself to compensate for that limitation. If there's a TAI-based "new Unix time", the leap second handling can be simplified a lot. The underlying time is always correct regardless of leap seconds. Sure, a missed leap second notification makes all civilian time faster or slower by 1 second, but the situation is the same for UTC if there's no time synchronization.
Why has it never been appropriate?
Because UTC has never worked that way.
UTC is an international standard for a "time of day" standard where every second is exactly one second long and is boundedly synchronized to the rotation of the Earth. But the Earth wobbles. The UTC solution is to occasionally add or remove leap seconds, so sometimes you see 58, 59, 60, 0, and we might someday see 58,0.
People complain that "leap seconds are hard" but there's a reason for them. Here are your options:
* If you want to always have 58,59,0, and you don't really care that time always increments exactly 1 second per second, then you can keep the time synchronized with Earth's rotation by smearing the time or having the time "jump" a little bit around leap seconds. This is what actually happens in many Unix systems. When we get near a leap second, the "seconds" are briefly not quite correct. It's a bounded error of a second or less and doesn't accumulate. For most people this error is just fine, which is why Unix time works for most people.
* If you want to always have 58,59,0, and you DO really care that time increments exactly 1 second per second, then don't keep the "time of day" the time synchronized with Earth's rotation. That's what TAI and GPS time do. But most people feel that ordinary civilian "time of day" should have some relationship to the position of the sun in the sky, which is why this is not the normal civilian "time of day" value.
* If you want to always have 58,59,0, AND you want time increments of exactly 1 second per second, AND you want time synchronized with Earth's rotation, then you need to regulate the Earth's actual rotational speed. I'm not sure how anyone would do that, but I suspect that will be very expensive :-).
You're better with something like epoch time because the duration between two times is always the absolute value of their subtraction. You don't have to store a chart to figure out whether the difference in wall time between 3:03:03 and 03:03:05 is 2 seconds or if there was a leap second and it should be 3 seconds.
You can do it, but you have to check the behavior of all your libraries. Which isn't fun. And make sure that somebody doesn't do an optimization that switches the behavior at some point.
[0] https://medium.com/@duspom/proposal-for-a-base-10-calendar-b...
I don't think that's how productivity works
I'd like to see not only switching to atomic time, but also to UTC globally, which would be far more convenient, but also may have it's own set of interesting minor discoveries
2. Summarising why I agree with 1.): With UTC (or whatever other time zone you'd standardise on), you "know" what time it is everywhere (because it's the same everywhere), but if you actually want to know what that means for people elsewhere (i.e. are they likely working/sleeping/eating/...), you'd still have to look it up, just like you need to look up time zones today.
At the same time though, because time loses its relation to the solar day, any mention of time you read or hear about in some article/piece of news/story/novel/... a) becomes completely meaningless without being tied to a concrete geographic location and b) if it's elsewhere, remains meaningless without looking up which bit of the solar day that time actually corresponds to at that location.
3. At the price of creating the International Date Line, the current system has the very useful property that the local calendar date changes at a time when most people are asleep or otherwise don't really care about it. With a single global time zone on the other hand, no matter what meridian you choose, 00:00 will happen right in the middle of the waking hours of a significant fraction of the planet. Having the calendar date change in the middle of the calendar is incredibly confusing and would necessitate using unwieldy double dates ("today is the 14th/15th") to make things unambiguous again. Public holidays and suchlike would have to be specified with starting and ending hours instead of being able to rely on the sensible default of midnight local time (and doing so would effectively reintroduce some sort of time zones through the back door, which calendar software would have to be able to handle, too – unless you want to force half of the world having their holidays starting and ending during typical waking hours)
Right now this is only a common problem when having to coordinate things with people in significantly differing time zones, but under your proposal, those unlucky people that are not living near the meridian will have to deal with it constantly when dealing with their local time (which for most people will be much more frequently that having to schedule a meeting with someone on the opposite site of the planet).
Arg 2, not knowing what reports meant - this would probably require saying something like "At 01:00UTC, early morning in Sydney Australia, Gov. Smith declared...".
However, the date issue might be more of a problem creator, as, I'm right now about 21:40 on the US East Coast, but it is already about 2:40 UTC, so my date would have changed about an hour ago. so, yes, less convenient until we get used to it.
Tho, when I work past midnight, it is kind of a 'so what'?
And, I literally had a meeting screwed up today because of time zones - and the guy I met with has to deal with China, India, EU, and US time zones - it's make his life a LOT easier.
Also as more people move off earth and work in orbit, on the moon, etc., and we need to communicate with them. What works best
Definitely requires more thought. Thanks!