Leap seconds are determined manually, though, so it seems like there's no practical difference other than UTC's error from solar time going out of spec?
> other than UTC's error from solar time going out of spec?
Well, yeah. Except that if it's not in-spec, it's not UTC; it's something else, and it shouldn't be called UTC. If you don't change the name, you would end up unable to compare two UTC times without also knowing which version of UTC the two times were given in.
I don't follow. UTC with no more leap second updates isn't a new version. It's the same timebase, just without any future updates to the leap second table. If the folk that maintain UTC decide to stop adding or subtracting leap seconds, it's not a fork in the timebase.
That fork already happened with TAI. TAI was the same as universal time in 1958, and has progressed without any leap seconds. The current offset between TAI and UTC is 37 seconds. We could all agree to switch unix time to TAI, but there would be a 37 second discontinuity.
I currently work on autonomous aircraft, and we use GPS time internally for avionics. The monotonicity is very nice for correctness when developing real time code. Outside of avionics, it's very confusing for people that tend to work in UTC. I've written table based timebase converters a few times now.
Well, yeah. Except that if it's not in-spec, it's not UTC; it's something else, and it shouldn't be called UTC. If you don't change the name, you would end up unable to compare two UTC times without also knowing which version of UTC the two times were given in.