Facebook/Meta has a lot of smart engineers working for it. I would have expected a bit more from these people than: "We don't like this solution please don't do it." i.e. an alternative solution.

From the article is sounded like they were adding support to an existing solution: run clock a little slower for a few hours around the time when a leap second is scheduled.

This has benefits and problems: it will work well with software that does not understand leap seconds. It will work badly with software that does understand leap seconds. It adds yet another possibility for confusion when computers using different time standards have to agree on the time.

Facebook are being reasonable here: identifying a problem. Pointing at one possible part of a solution. Not inflicting a solution on the world that only solves only their own problems. Trying to get the problem addressed in a forum where many stakeholders have a voice. Hopefully we will end up with one more time standard that suits many people instead of dozens of new ones.

Have all the Tesla cars start up and head off in the same direction at the same time, thus applying enough force through friction to speed the planet up by just enough to counteract the slowing down!

(c)Meta 2022+a leap second

The cumulative effect of them eventually stopping would reverse this. To avoid it you'd have to keep them going perpetually.

Their timekeeping is peskily imperfect. I'm for accommodating the one we've got, rather than moving to perfect planet Zuck.

Zuck is welcome to move to move to another planet (and stay there), where he can specify any time system he likes.

Introducing Facebook and Meta is a risky practice that does more harm than good

Can't we just smear both of those organisations off the face of the Earth?

All of the problems identified are down to crap software implementations that do not allow for leap seconds or are simple not tested . Over the same periods many systems just kept going and nothing troublesome was reported.

So maybe they should actually test their systems on known and predictable-a-year-ahead events before deploying them?

Also worth noting that for decades there are systems that get round these issues by keeping either "GPS time" or TDT and then applying an offset, just as DST hour changes and global time zones are handled in UNIX. So there already are tested solutions to this problem if you simply cannot allow for non-uniform time.

So how many other software systems have fallen over on DST changes? Remember Windows 95 doing that?

So how many other software systems have fallen over on DST changes

Millions. All those cron jobs set to run between 1AM and 2AM on Sundays.

Netware 3 - But suspect both W95 and Netware predated (huh!) the UK change to a more predictable date for switching to/from BST -"Summer Time Order 2002" I think

It won't run jobs twice when you fall back, and it will run jobs scheduled between 1AM and 2AM on Sunday immediately when you spring forward.

"Millions. All those cron jobs set to run between 1AM and 2AM on Sundays."

I run mine at 3:00 AM avoiding the problem.

So if Zuck gets his way, there wouldn't be exactly 60000 ms between 00:00:00 and 00:01:00 on a leap second day? That's astonishing behavior and tbh I'd rather keep intervals exact and live with an extra inserted second, than have intervals perhaps off by a few hundred ms, if they're a few hours in length. Imagine playing a two hour movie and discovering that your audio/visual sync gets progressively more and more fucked up because naively taking the system time and assuming 1s = 1000ms = 60 frames = 48000 samples breaks during leap second smearing :/

Meta are free to switch from using UTC to TAI or GPS, if they so choose. They don't have to persuade anyone else to do this.

The impact will be on libraries which convert utime to human-readable date/time: those will need changing to account for leap seconds. I'm sure Meta can afford the resources to maintain their own libc fork and their own TZ database.

Their applications will also need to be careful not to hard-code things like

day = utime / 86400

time = utime % 86400

which are quite tempting short-cuts for programmers.

I understand the problem leap seconds are solving, but do we need them? We are talking about a difference between two ways of "measuring" time that diverge by about a minute every century. If we just just stop adding them and let the two diverge it it's going to take >5,000 years for it to make an hours difference. We are very happy and generally cope with applying an arbitrary one hour DST correction to our time a couple of times a year (with the exception of those countries that don't do DST). All that would need to be done to fix the divergence of the two time systems would be to cancel one of those two arbitrary DST changes every 5,000 years. The people who need to be aware of the difference between the two methods already are familiar with there being a offset between them and how this changes as leap seconds are added. They should be quite capable of coping with this offset getting a bigger over the next 5,000 years. For the rest of us its a minor change to the way the DST change is calculated in 5,000 years.

They make little or no difference for us on earth but they make a huge difference for anything that uses the position or the orbit of the earth for reference such as all our navigation systems.

I agree, but why even adjust at all? In modern society, there is no real need for the calendar year to coincide with the solar year. Already now it doesn't: Midwinter is ten days before New Year, so letting it slide even further doesn't matter. Our months don't coincide with the phases of the moon, so why should our year coincide with the Earth's orbit around the Sun.

We could even drop leap days every (roughly) four years, and it wouldn't matter. We could even decide that every other month is 30 days and the rest 31 days (getting rid of the irregularity of February), making a year 366 days instead of 365.25 days. Or we could make months 30 days each, which makes a year 360 days, which divides evenly by many numbers -- the reason we have 360 seconds to an hour and 360 degrees to a circle. And while we are at it, drop time zones and use CET everywhere. So what if school starts at 03:00 in some countries and at 17:00 in other countries?

Astronomers already use a different year that aligns with the positions of stars (other than our own), called the sidereal year, so they can keep using astronomically accurate time, but the rest of us don't have to.

And has been for years, and most other nations agree. Unfortunately unanimity is required and the two big holdouts are China (“our culture requires time to be aligned with the seasons”) and the UK (“nothing should ever be done for the first time”).

Just let UTC tick without the leap seconds, apply them to GMT instead. Then offset local time zones from GMT instead of UTC.

Software can catch up slowly with the new plan or not at all.

Smearing is ok but not great. For those who are against it, have you considered what your computer does when the NTP servers tell it it’s fast or slow?

Yes: just count seconds since the epoch and things become simpler.

Put the complexity on converting epoch seconds to a form that a human will understand. That is already quite complicated as it has to cope with time zones and daylight savings. This can have 1.30 am happening twice on some days or not at all.

Part of the problem is that POSIX defines a day as 24 x 3600 seconds, it does not allow + or - 1. Fixing this would be hard (lots of legacy software to check), then the conversion code but would then let us count seconds.

It's a good idea, but it solves the wrong problem. What we need is to smear the leap hours that cause us so many problems when we make them go forward or back for "daylight saving". Let's introduce leap minutes every day for 60 days, then 60 negative leap minutes, when we need to put the clocks back. Let the machines handle that and our bodies won't notice. Bonus, your kids won't try to get you up an hour early when the clocks "go back".

The ensuing debacle night persuade us to abandon "daylight saving" altogether.

Please arrange to do this on the exact moment I get paid every month, so that the payment system goes back in time after the first payment is made, and then pays me again a second later.

However you choose to mess with time, there will always be edge cases like this that cause problems.

A system of massive rockets attached horizontally to the Earth's equator to be fired occasionally to correct the Earth's spin to match the clocks. Problem solved.

I'll get my coat, mine's the one with the copy of Mad Scientist's Monthly in the pocket.

Leap milliseconds applied or not as needed on a daily basis.