[jabl]

UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies.

Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:00 being noon, at least at some point in each timezone, but calculations with UTC seconds would not need to bother with leap seconds.

[bloak]

If people don't like leap seconds, there is no need to redefine UTC; they can just use TAI today. That gives them the additional advantage of not having to handle leap seconds in the past, because software that handles historical UTC timestamps will always need to know about the leap seconds that have already happened.

[nullc]

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.

[blahgeek]

I think the problem is that we already have the networks and protocols to synchronize time (NTP, PTP, etc.), but not for timezone DB data.

[mlichvar]

RFC 7808 specifies a TZDIST service.

But most operating systems already have their own mechanism to update their timezone database. This is not a problem. Shifting timezones by 15 minutes every few thousand years would work with current software.

All we need to do is to agree that UTC will have no more leap seconds.