All I want for Christmas is a negative leap second

"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth.

Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak.

That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg

> Is there a single system currently in existence which can handle a leap minute?

Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST.

So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second.

And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.

I think it's weird how people react with such horror to the idea that maybe, just maybe, it wouldn't represent any kind of problem to the people of the 23rd century if 12:00 didn't correspond to the instant the sun was directly overhead, but instead a minute past. Nor would it cause any issue for people thousands of years from now if 12:00 was in the evening or the morning or any other part of the day or night. For those future people it would simply be the way things are, and it would stay that way their whole lives.

Riffing on “if it’s painful, do it more often”, I wonder if mandatory leap seconds every year, but trueing up the delta from N years ago, would be a good compromise? Regularity makes it easier to plan, and 6 months’ notice is not really enough for many OS distribution paths (eg IoT, embedded).

Since the list of delta updates is queued, you could bake N years of updates into your system if it’s a fire-and-forget OS. A number in between 5 and 10 seems reasonable to me, but seeing as we are discussing living with 50 years of drift it could be higher. And sure, for this to work, allow non-integer deltas again; or just have a rule that you round the applied adjustment down.

Seems no harder to bake in the last 50 years of leap seconds as to include to Olson TZ database in your distro.

I have never understood why POSIX and NTP timescales work the way they do. They are positively bonkers when it comes to leap seconds. Time isn't even monotonic during the transition, because the epoch itself is redefined.

Contrast this with the GPS or PTP timescales, which simply count seconds since a well-defined epoch. Formatting the date and time for humans to read is a sensibly separate process.

I don't even see the need for leap seconds at all (in either direction). Why should anyone care? All times are relative to some arbitrary fixed point in time anyway, so why are we so hung up on maintaining the status quo?

Aside from the fact that just by ignoring the problem it'll probably go away - we've just had a period of adding a load of leap seconds to roughly compensating for the Earth rotating "too slowly" overall, which for a system that's inherently irregular and actually speeds up and slows down all the time, and just happens to have been "too slowly" ON AVERAGE. It now seems hat the rotation speed, on average, is "too fast" and now we need to undo some of that adjustment. If we'd just left it alone, it'd have been fine.

And for all the hassle these leap seconds cause, what exactly has been the benefit? Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later.

Just think, in 100 years, when your great grandchildren are enjoying their life, we might be a whole minute wrong. And if you went the other direction, back as far as all of recorded human history, and we might be out by an hour. Many of us are routinely forced to have our clocks out by an hour for "daylight savings time" every year anyway.

For the very few cases where it might be useful to know the ACTUAL difference between the rotation and alignment of an abritrary fixed point on earth and an arbitrary fixed point on the sub, then THEY can use they own clock for that specialised purpose. And maintain a fixed adjustment to the atomic clock based time that everyone else uses, and they don't even have to round to a whole second for that - they can say NASA time is TAI+1.234s for instance and the only people who need know or care is NASA themselves.

> You've reached a situation where campaigning for the whole world to change the way it measures time is simpler than fixing your code?

It isn't just a code problem. Since leap seconds aren't predictable, you have to somehow distribute information about new leap seconds to everything, which is especially difficult for devices that aren't connected to the Internet.

And as the article mentioned, there are multiple ways to deal with leap seconds, and there are tradeoffs involved in choosing which one, and depending on the circumstance different ways. And since different methods work best in different situations, that can result in inconsistencies between different systems.

qntm, I know you're reading this. As someone working on software that works on ships (aka, software that needs to change timezones and locations often and still maintain contiguous millisecond accuracy of all shipboard equipment events), this article has caused me significant psychological damage.

There Is No AntiTimekeeping Division ...

I gotta say I like this QNTM cat. Wrote Hatetris, "There Is No Antimemetics Division," and Absurdle. A fun explorer of adversarial computing environments. Pretty interesting

Maybe there should be an analog of the Kardashev scale for civilizations capable of adjusting the rotation speed of their planet in order to make timekeeping easier.

I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...

Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is.

Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint.

We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them.

Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.

Or we could adopt the "smearing" technique in either direction and we could do it hourly or daily or weekly or monthly or half-yearly or whatever interval as agreed.

Maybe we should do it every 6 months no matter what. That way, everyone would know that on June 30 and December 31, there would be smeared seconds.

That makes the "do it rarely and people will screw it up" problem go away.

If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!) How you want to display that in various timezones i do not care

Just make leap seconds first class.

https://gavinhoward.com/2023/02/make-the-leap-second-first-c...

Negative leap seconds seem like they shouldn't be much of a problem. At least they don't involve repeating a second.

No queries came in during a whole second? Who cares?

So my assumption was that Unix timestamps were monotonically increasing and that for the case of leap seconds the conversion from timestamp to UTC would take those into account and for some seconds have 2 mappings. That would keep the ordering of events, it would break assumptions like a day is 86400 seconds.

But I guess they decided to keep that invariant, which makes negative leap seconds really hard. Maybe that’s a good trade off.

Almost nobody ever cares for UT1 except for astronomical observations (where you are also likely using a different calendar and using sidereal days) and we already have a perfectly working system for relating local times to each other and to UTC: timezones.

The only things we should care about are local time (both as in clock time and in sun-position time) and universal timestamps to coordinate between local times and to use as canonical representations; leap seconds are useless or damaging to both of these.

We already easily accept over 60 minutes of offset between clock time and sun-position time and I do not think that 3600 seconds can be ok but 3601 or 3599 cannot.

It is also perfectly easy for a country to change its timezones or to adapt a non-whole-hour timezone (multiple countries have 15 or 30 minutes offsets)

So my proposal is that the IERS never announces any leap anything ever again and in a few centuries some countries will shift their timezone by 15 or 30 minutes.

This will be much more easily compatible with all current systems (we can right now create the timezone CETP and CETM for central European time plus 15 and minus 15) and in 400 years each at they leisure Europe/Berlin will be equivalent to CETM* (and CESTM if have failed to remove DST).

No need to handle irregular minutes or hours, no fractional seconds offsets, no need to account for edge cases that are far too easy to ignore, just keep writing code that work with timezones (as you should already be doing) do not hardcode conversion between regional timezones (Europe/Berlin) and offsets (CET, CEST, CETM) as you should already be doing just updating your timezone tables (as you should already be doing as they change often).

Just store one of:

- UTC and timezone

- dateless time with/without timezone

- date with no time with/without timezone

And you are ok, already prepared for the next few centuries of no leap seconds.

* I don't know whether it would be CETM (that is +00:45) or CETP (+01:15).

The solution is obviously to have a leap second every half year, even when the difference with solar time is too small. Just alternative positive and negative leap seconds, and for additional fun, don't have a leap second when the difference with solar has shifted (in the right direction; it should be possible to keep the difference less than 1.5 second, probably much less). We could even do this every month, just to make sure there's enough testing opportunity.

Leap seconds are an extremely Earth-centric concept.

There is no mention of the affect this might have on investing or wagering.

Or is the author keeping that close to the vest?

You need more than a negative leap second to get anytime close to Christmas, though.

If the IERS ever announces a negative leap second, they should do it like this:

https://m.youtube.com/watch?v=fr1li5NaltA

Always facinated by how complex standardizing timekeeping is. If here was a chance for a global redo, would there be a more simplified system?

On leap minutes:

> Because there's nothing computer programmers handle better than special cases which only occur every hundred years or so. How in the world could this be an improvement?

If it's less than 60 times as disruptive, it's an improvement.

> everybody's going to hate it at least sixty times as much as they hate leap seconds now

I doubt that.

> If something is difficult, you do it more often.

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.

> But before 1972 UTC and TAI were kept in much closer synchronisation [...] (No, I'm not advocating returning to this state of affairs.)

Coward! But seriously, I think this hurts the previous argument significantly.

I had to recreate an account just to reply to this discussion because I'm so appalled by its content. At the time of me writing this, 99% of the comment here are complaining about UTC moving to keep track of solar time or smugly arguing that we shouldn't do that.

Different time standards exist. International Atomic Time (TAI) is a strictly monotic clock based on the average of multiple atomic clocks throughout the world. UTC is defined as a tweaking of TAI to approximate UT1, a rough definition of which would be the historic mean solar time at longitude 0. UTC shifts TAI to be within one second of UT1. That's both its definition and the whole point of it even exising. I repeat, it UTC didn't track solar time, it would have no reason whatsoever to even exist.

If you want TAI, just use that. Stop complaining that UTC is not it.

I don't understand that someone just want chaos. I guess "Some people just want to watch the world burn".

But negative leap second shouldn't be so noticeable since it will just be a jump from 31 dec 23:58 to 1 jan 00:00.

Facebook made a lot of FUD about a negative leap second but I don't think it should be THAT a concern.