I'd push for making it an hour already.

If synchronizing our clocks with the Sun is still important by then, then announce it a decade or two beforehand, and make a large ceremony out of the thing.

You don’t need to announce it a decade in advance. Time zones change all the time, we already know how to handle it and it requires no global coordination. Some country announces that part of its territory is changing time zone, the tzdb is updated, and everything continues working fine for everyone. This happens a few times a year already.

Sometimes on quite short notice too. https://codeofmatt.com/on-the-timing-of-time-zone-changes

> It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain.

Yeah, if we're not going to abolish leap everything in UTC completely (which I think we should) then leaps need to happen at most quarterly. When the last leap second came through it was long enough since the one before that the bugs in Linux had been fixed and then unfixed.

Do we introduce an unnecessary leap second and then negative leap second every year just to keep the gears oiled? And then if we need one for reals we can increase it to two leap seconds added and only one removed. Though of course that will cause bugs in any code that isn't expecting two leap seconds to be added and assumed that there would only ever be one. sigh

Just accept that time will very slowly drift over the period of many centuries. It's really not a big deal. It's a complete non-problem that doesn't need any solving. Especially since coming up with a robust scheme that will work over the period of many centuries is quite hard (the current leap second system doesn't suffice).

> It's really not a big deal.

Unless, of course, you are a satellite.

I don't know what you're talking about, but as far as I know satellites can work perfectly fine without a leap second. I'm not aware of any practical advantage of leap seconds anywhere. The only difficulty in abolishing the leap second is that some systems have it incorporated in their protocol, but that's a protocol issue and not an intrinsic time drift issue.

Time is attached to the orbit of the earth (very precisely) so when time goes out of sync of the earth, it won't be a good day for anyone.

Most satellite systems don't use leap seconds; you don't need leap seconds to have satellites. And leap seconds don't really "sync time with the earth"; that's not how any of this works. Whether it's now 13:04:00 or 13:04:27 is somewhat arbitrary and all leap seconds do is maintain a certain arbitrary definition.

Orbiting around earth is going to be based on sidereal time, which drifts 4 minutes per day.

Converting into normal units has no reason to care about leap seconds when it can use the actual offset and be a few orders of magnitude more precise.

We could build it into daylight savings time. Instead of jumping an hour, we announce what the jump will be every year.

Not everyone's jumps happen at the same time (or ever).

We already have non-integer timezone differences. We could allow for leap seconds in that. Europe's timezone could be UTC+2:00:01 while the UK is still UTC+00:00:00

That has all the same legal difficulties as removing leap seconds from UTC (indeed it sounds like you would remove leap seconds from UTC).

It vaguely feels like it ought to happen yearly. Yearly, but no option of a shift of exactly zero, so everybody knows it is coming every year no matter what.

The obvious disconnect is the digital bits inside my hardware clock shouldn't need to care about any of this. Then you can change it as often or as little as you like.

I assume you mean high precision clocks in computers because an actual clock won't care about half a second.

You could use TAI-ish timestamps right now, but people are going to get confused and make mistakes if your timestamps are almost UTC but several seconds off. And if UTC stays constant then you need to nudge all the time zones around and that sounds even worse.

So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.

I think the later is less fraught with problems and doesn't require software changes in order to realize updates.

You're going to have to deal with the offset one way or another. I'm simply suggesting a means to keep the offset but not have to worry about how to realize that in terms of complicated hardware hacks.

> So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time.

That's a choice we have right now, today, and as far as I'm aware nobody chooses TAI for their systems. I think that says a lot.

> You're going to have to deal with the offset one way or another.

Most things don't really care. Oh the clock's off by 1.7 seconds, let's make an adjustment and check again tomorrow. Leap seconds are below the noise floor.