Spoken like someone who hasn't attempted this. :)

All our computer and protocol infrastructure is setup to handle and distribute UTC. Everything else you talk to is speaking UTC.

Trying to use TAI in a UTC world doesn't save you from dealing with leapseconds in the slightest: You get all the leapsecond induced problems just obtaining TAI from your UTC feeds and them you get them again at every boundary where you need to communicate with something else that is using UTC.

At least if you use UTC across the board you'll only fail around leap seconds (or false leap seconds created by issues in leapsecond distribution infrastructure). If you attempt to use TAI you'll get those failures plus many extra ways to fail.

> that handles historical UTC timestamps will always need to know about the leap seconds that have already happened

That's static data that can be hardcoded and tested, massively easier and safer than events which are being inserted (or accidentally failed to be inserted) in real time.

The big problems with leapseconds arise because of the realtime discontinuity and because the offset function changes in unpredictable ways.

In many applications there just isn't any old dates to begin with. E.g. in my code that points my telescopes (and determines where they're pointed from the encoders) I have a pile of nonsense to hopefully handle leapseconds, which may or may not actually work right when one happens as its really hard to test how other software will behave. But the same software never needs to handle times more than a day (or a few days) in the past.

If leap seconds stopped being issued bugs in software impacting billions of people would just vanish. Not every bug-- some things might also mishandle historical leap seconds, but most of the issues come from realtime bugs. If you go too far back times wouldn't have been known to 1 second in any case, so bugs with historical data would mostly be in the form of things breaking due to inconsistent time difference calculations.