Your servers stop losing a second in May 2027

A server that reboots for no reason. A backup that fails at 23:59. Two machines that no longer agree on the time of an exchange. An SME owner does not need to understand astronomy to know that kind of morning: it is enough that one system decides, on its own, to reset its clock.

The news is good. The International Bureau of Weights and Measures has ruled: the leap second will officially disappear on 20 May 2027, as ZDNet France reports. No more 23:59 and 60 seconds. No more phantom second slipping into data centres and unsettling machines that never asked for it.

What was really happening inside your servers

The leap second existed to align atomic clocks with the irregular rotation of the Earth. On paper, it is elegant. In a data centre, it is an unexpected jump. In 2012, players such as Mozilla and Reddit suffered heavy outages because of that shift, the article recalls. A single second of difference can corrupt financial records or desynchronise whole clusters of servers.

To compensate, large platforms each built their own recipe. Google, for instance, spread the second over twenty-four hours. Every player applied its own method, and that patchwork became a risk in itself: two systems that handle the jump differently end up disagreeing on the time.

The scenario that worried people more

The ZDNet piece highlights a point few business owners had in mind. With the recent acceleration of Earth's rotation, scientists feared having to subtract a second rather than add one. Adding time already causes outages. Removing it would have been worse for most network protocols. Removing the mechanism before 2035 closes that door before it opens.

Astronomical time will drift slightly from atomic time. It would take centuries for the gap to reach an hour, the source states. That is not your company's problem. Machine stability, on the other hand, is.

What it changes for you, in practice

You do not run time servers. But someone, in-house or at your provider, may have written scripts to absorb those clock jumps. Those scripts will become useless, then awkward. That is dormant technical debt. The right question is not whether to delete them now, but whether anyone still knows why they exist.

• List the machines that depend on a synchronised clock: servers, backups, exchanges with the bank or payroll.
• Ask your provider which workarounds were put in place for the leap second, and which can be removed.
• Check that your continuity plans do not rely on a mechanism that disappears in May 2027.
• Keep the date in mind for future infrastructure changes, without turning it into an immediate project.

If you want to know what your servers actually do with time, we can talk. An hour of review is often enough to spot forgotten scripts and fragile dependencies.