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.
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.
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?