Leap smear is itself an overwhelmingly bigger problem than a leap second.

A leap second is over in a second. With leap smear you are out of sync with the rest of the world for many hours. And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again.

The sensible alternative would be to eliminate leap seconds entirely for a few decades, and maybe stage a leap minute, eventually, or a leap hour in some far-off century, or never. It doesn't matter if the sun is ever exactly overhead at noon, because it isn't anyway, almost everywhere.

It's not particularly interesting to be out of sync with the rest of the world, you always are and messages to/from external entities are even more so constantly. When it is interesting is when the thing you are doing is a function of time e.g. GPS or locked-step systems spanning geographic regions or so on. In almost all of those cases you're probably well used to dealing with time problems that are a bigger pain than a leap second. For those that aren't hiding the leap second and being off by slightly more than usual for a bit is probably better than hoping everyone can be prepared to suddenly care a lot about handling time oddities for one second every year (or century as you propose).

"Or never. Is never good for you?"

Only a positive leap second is “over in a second”. A negative leap second is essentially “over before it starts”. This asymmetry is an opportunity for code to implement UTC incorrectly.

Another issue is that a positive leap second cannot be represented using time_t-like representations. But at least every time_t value maps to a UTC time.

By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun.

> By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun.

Positive leap seconds, when translated into a dumb format and back, can be off by a second and won't round trip properly.

Negative leap seconds, when translated out of a dumb format and back, can be off by a second and won't round trip properly.

Seems pretty close to me.

> And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again.

There's also the exciting version where some of your time servers do it one way, and some do another; you could probably pick two traditional servers, and then one of each of the others and have a really terrible day. From experience with a setup where 4 servers were traditional and one was smeared, there was a lot of variation in time; but thankfully my systems weren't relying on time measured on different servers to be very consistent.

IMHO, leap smear probably should have been done with standard time on the wire, and the host agent doing the smear. But that would be more effort than doing it on the time servers, so there you go.

If I've learned one thing about dealing with exceptional events, it's that the less often they happen, the less likely you are to handle them well. Switching from leap seconds every few years to leap minutes every century, pretty much guarantees we'll screw it up. But maybe that's ok? Y2K was a fat nothingburger, after all the fuss.

It's a little like a public health success: if done right, the worst that happens is that people have to prepare, and people complain about it, but disasters are avoided.

Pre-Y2K there was a lot of fuss and hand-wringing, but there was also a lot of software development that happened to ensure that Y2K would not be a disaster. So then when Y2K rolled around the preparations mostly worked.

My first programming job in high school was over-hauling a (mainframe-hosted) code base for handling lab data at a hospital. This was in the mid-90's; before most of the Y2K fuss had started. Without my work, pee and poo samples would be time traveling from the late Victorian era. You're welcome.

Y2K was a fat nothingburger, because of all the fuss. Millions of person-years and $300 billion were spent to avert disaster - and it worked!

But then all anyone ever sees is that nothing went wrong, and they assume it was nothing to begin with.

That's why we should eliminate leap seconds/minutes/hours and just change time zone definitions to keep the sun overhead near noon.

Is the concept that UTC would become "detached" from a particular location on Earth and the offset of time zones relative to UTC would change over time (very infrequently since it would take on the order of a millenium for a time zone to shift by half an hour).

Exactly.

Push it out to a century, and then hope we have the ability to slightly accelerate the planet by then?

> A leap second is over in a second.

The problem isn't one where you hold your breath and squeeze your eyes shut for a second while the unpleasantness passes. The problem is when you have tons of code running and you don't know exactly how it'll deal with this very rare event.

If you're faced with an upcoming leap second there are various ways of dealing with it. One way is to do an audit of the code and hope that you can verify the most important parts. Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off.

There are other options, but I don't think there's an "obviously correct way".

> Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off.

> There are other options, but I don't think there's an "obviously correct way".

Well, there are ways that following reality more and less. There are also ways that have legal traceability to time sources in some regulated industries.

> a leap hour in some far-off century

Just change your time zone offsets at that point, honestly.

> Applying it to millions of individual servers with different OSes? I'll make the popcorn.

The FreeBSD folks test for this:

* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...

The kernel and ntpd are fine with it. Applications: ¯\_(ツ)_/¯

> I'll make the popcorn.

Too late, your IoT-enabled microwave just crashed and can't heat up the kernels