Actual research astronomer here, and as a (radio) astronomer I would love to get rid of leap seconds. Assuming that UTC = UT1 (the time measure based on Earth rotation) is not accurate enough for most calculation such that you already need to use UT1 tables/forecasts and leap second tables in your ephemeris calculations so there isn't really much benefit in trying to keep UTC close to UT1. And the reality is that for us they actually make things worse: we stop data acquisition at the telescope over the leap second period because we timestamp our data in UTC dealing with the changing interval would be a pain.

There are some good arguments for keeping leap seconds, but I don't think research astronomy is really one (it might be more useful for amateurs), particularly on ~100 year timescales where you don't expect things to slip that much. I think this sentiment is shared by most of my peers, particularly those who actually have to implement data acquisition and analysis pipelines!

The thing is, similar reasoning can also be used to promote getting rid of leap years. Heck, maybe just switch to 12 months of 30 days while we are at it.

If you want to use real-world time, you have to make sure it stays in sync with the real world. Switching to something which is close-but-not-quite-correct will cause even more issues than we are currently having with leap seconds. Can't deal with that? Well, just use the Unix timestamp like the rest of us?

The issue is that all timekeeping is going to be an approximation of our messy Solar System. The only question is, "How accurate is accurate enough?"

Currently our calendar goes off by one day in 3236 years. If the history is calendars is indicative, in about 10,000 more years we may change our calendar. (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)

Our clocks predict astronomical time of day to less than a minute for a human lifetime. And both DST and timezones demonstrate that we're happy to live with the clock and Sun disagreeing by an hour or more.

My position is that both are currently good enough for the next couple of thousand years. And we can let our distant descendants sort it out when the time comes.

> (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)

It’s more likely that every planet will have its own calendar and you’d have to do the conversions and translations. That’s what scientists do with Mars time. Thanks to relativity, time at point A is not the same as time at point B, and whether they stay in sync for you depends on how you get from A to B.

The calendar point is possible. But the special relativity point, not so much.

While "now" can vary according to the time it takes to get from A to B, all observers can work out what "now is according to the reference frame of the distant stars". On a mere interplanetary scale, this idea is amazingly precise. We might not agree on how much time passed (this has already mattered for GPS satellites), but for all practical purposes "now" is perfectly meaningful.

Yeah, looks like it would work out fine. Since synchronous communication breaks down pretty quickly even on merely interplanetary levels, the remaining use for calendars and timekeeping is basically event planning. For that difference in reference points and interval duration is not that important, as long as you can compensate for that, making events happen at a time you expect in a place you expect. We're doing that fine already, communicating with our deep space probes.

Yeah, if it wasn't for that pesky requirement to keep in sync with the wall clock, my life would be so so so much easier not having to deal with drop frame timecode. The video industry isn't exactly small, and nobody has just up and decided "meh, it's too hard, so we're going to push the everyone else to do what we want". We all put on our big boy&girl pants and do the work.

Of course, drop-frame timecode itself imperfectly compensates for the fractional framerate, and also as a result of the math not really working out there isn't a drop-frame standard for 23.976 fps at all, so sometimes the industry just throws up its hands and says "meh, it's too hard."

It's not that they don't have DF for 23.976 because it's hard, they don't because it wasn't needed. A 23.976 framerate was never broadcasted as it wasn't part of the NTSC standard. In fact, rarely did anyone actually edit at 23.976 unless it was going back to film. They cut the telecined film as 29.97 video with no regard to A-frames or any other methods that would enable the edit to cleanly go back to source frame rate. They so didn't care that some times the film cadence changes on every single edit. Why? Because nobody needed it nor could they possibly imagine the time of the internet and digital streaming that could do any frame rate to even bother wasting time trying to do it "right".

Well it _is_ in the standards now and you still see just non-drop timecode being used on it, with the resulting noticeable skew from wall time as the duration gets up there.

Again, it is not a broadcast standard, at least in the US. Pretty sure it's not in non-US markets either. Sure, it's a format that modern decoders and monitors can handle, but it's just not a format that people are concerned about it matching wall clock.

23.976 is in ATSC I'm pretty sure, but I take your point that in practice it's not used for broadcast.

The video and music industry has been screwing a lot of our digital lives with mandatory encryption and anti hacking/reverse engineering requirements just to sustain some of their business models. The abstraction layer is different than this, but god the irony.

I can see that, but I disagree that it's enough of an explanation. The blog specifically gives an example of the Earth's angular velocity changing with the melting of ice caps. They even threw in a cute animation of an ice skater to explain it. Last I checked, we're in the midsts of global climate change which is rapidly melting our ice and raising sea levels. I'm supposed to take Meta's word that we'll never need another leap second then? Why is that the case? Instinctually it makes sense to me to have a clock that follows the Earth's rotation. Why does Meta believe this is no longer the case? The only justification I saw was "it's hard" followed by their explanation of how they've solved it already. So what is the problem that's being solved by not counting leap seconds?

So, time is a human construct and Earth doesn't care how we measure it.

It's not that we'll never need another leap second; we could add ten, negative ten, or zero in the next 25 years and Earth won't care. Who will care are humans, who may get a bit annoyed when the sun starts setting in equatorial latitudes at 3PM.

Based upon the historical trajectory, it would take around 6,666 years for time to be offset by 1 hour.

Why can't large tech companies that need synchronization similarly switch to an alternative time without leap seconds?

Because they are lazy and are not aware of the prior work.

Already decades ago many have proposed to use only TAI internally in computers, instead of UTC, which is not a time.

UTC should have always been used only to compute the local times, together with the time zones, only for human interfaces.

There have been for decades libraries for using TAI instead of UTC, and even versions of Linux or *BSD kernels patched to do time keeping in TAI, not in UTC, eliminating all problems with the leap seconds.

Unfortunately the use of TAI has remained a niche, but that was the right solution.

Worst part is, the arguments are a bit silly.

Time may change forwards and backwards, because my computer clock may be fast or slow. The same logic to correct for leap seconds, can be used if my computer is 2 sec fast.

And your code had better handle it, and the os, libraries, it really is only hard ), if you have to support 1000s of novice devs.

And FWIW, every major company does have to support a thousand novice devs, every year, over and over, forever.

Honestly, this issue screams education problem. "Time is a mess" should be taught alongside buffer overflow attacks and networking theory (in fact, networking theory is a great place to teach "time is a mess," because you can roll it in alongside ideas like "simultaneous action is a lie" and "clocks are always wrong anyway").

Because time in the real world uses leap seconds. The time businesses open and close. The times reported in news articles. And so on. What facebook wants is for all of them to stop using leap seconds so facebook’s infrastructure is simpler

Times reported in newspapers are not granular enough that it’s even possible to notice whether leap seconds are used.

It's not just Facebook. A large community doesn't want them.

https://www.cl.cam.ac.uk/~mgk25/time/leap/

Time in the real world can use leap hours, the next of which will be in approximately 3000 years.

The article you linked seems to be arguing pretty strongly against leap hours. I'm not sure we could solve all those problems even in 3000 years. Can we compromise and use leap minutes? That way the problem is a bit more immediate, in 50 years we're sure to have solved it; or we'll all be dead and it will be on someone else!

Instead of leap hours we could just permanently abandon leap anything, and state that the offset between UTC and TAI is fixed at 27 seconds from now on, forever. Every few thousand years, when this new UTC has drifted enough from solar time on the prime meridian for people to start noticing and caring, countries can decide to simply change their offset from UTC, which will just be a normal update in the time zone database that doesn’t need to be coordinated with anyone else, i.e. something that already happens quite regularly.

This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to).

I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.

Yep, either just redefine the timezones-- or perhaps better just issue new "New Eastern time" that is offset by an hour.

> lose the prestige of being the place that global standard time is based on.

You joke, but that's actually a source of some of the opposition. :(

Brit here.

It infuriates me that the BBC World Service insists on announcing the time as "<something> GMT", pronounced in a smug tone of voice. The GMT timescale no longer exists; nobody broadcasts it. What the announcers are broadcasting is the BBC's ignorance. I find it embarrassing and jingoistic.

They've also adopted an idiosyncratic way of pronouncing the time itself: "The time is Four, GMT". Everyone else says "Four O'clock", or "four hundred hours" or "four AM". The Beeb are almost completely immune to complaints; they've outsourced their complaints department, and the contractor's brief is to make sure no complaints reach programme makers.

Because they have to interact with the rest of the world, and billions of lines of computer software and hundreds of thousands of protocols have been written to use UTC instead of, say, using TAI and computing UTC on a presentation basis like timestamps are handled.

I can't imagine people who need accurate timekeeping (like scientists, astronomers and the telecom industry) preferring UTC over TAI. They do however prefer UTC over UT1. UTC was a reasonable compromise in the sense that it's almost TAI, but is close enough to UT1 that you can get all countries on board without much effort. Imagine getting the whole world on board to accept a mysterious device that counts electron transitions, without giving some kind of reassurance that it won't deviate in any relevant way from the timekeeping system they are used to.