Why Leap Seconds Cause Glitches

In computing, there’s a concept called Unix
time. It’s the number of seconds since January 1, 1970. Loads of programmers use it, because
it’s really easy to deal with: it means that instead of having all these messy months with
different numbers of days in each of them, and this weird thing where February has an
extra day every four years, except when it doesn’t — you’re dealing with just one number.
The bigger the number, the later something happened. Easy. As you might know, there is a leap second
tonight as I record this, because the Earth’s orbit is slightly irregular. And that’s a
problem. Because there are two ways that Unix time could deal with leap seconds, and both
of them suck. Option 1: include leap seconds. Unix time
just keeps ticking on. That’s not bad in theory, but in practice it means that any implementation
of Unix time that converts between it and human-readable time needs a database of every
leap second that’s ever happened, and an update whenever the decision to add or remove a leap
second is taken. Otherwise when you say “6pm”, an old system that’s missed leap second updates
might understand that as a few seconds away from 6pm. Not important for most of the world,
but kind of important if you’re working out the timing for, I don’t know, docking a satellite.
And good luck getting that vital leap second update to the satellite you’ve already put
in space, or to the secure system that’s cut off from the outside world. Okay, so including leap seconds sucks. But
not including them — which is the second option, and the one that we as a species went
for — also sucks. It means that Unix time isn’t really the number of seconds since January
1, 1970, it’s just a number you can calculate from whatever’s on our human clocks. And because
tonight, 23:59:59 is going to happen twice — officially, it’s 23:59:60, but good luck
getting that through any computer system — 23:59:59 is going to happen twice — that means that
Unix time is going to repeat a second. The key advantage of Unix time, that a bigger
number always means later? Not for those two seconds. And that’s such a weird edge case
that it’s going to cause some minor glitches somewhere. How? No idea yet. Why? No idea
yet. Could be something as simple as a process that’s meant to run once a second, that would
save a file out with the current timestamp as its name — it’s bad design, but an easy
mistake to make. That program will discover there’s already a file with that name, and
if it’s badly designed, it will crash. That’s a really simple bug, any actual problems will
be massively more complicated and subtle than that. Don’t don’t worry about your desktop
computer and your phone: you can set the clock forward and back months on those and it probably
won’t mess anything up. Google’s got a really clever solution — a
leap smear, which steadily stretches out the second over the course of the day. Yes, the
clocks will be inaccurate by up to half a second, but their priority is making sure
that time is linear, the accuracy doesn’t matter so much. And some stock markets are
taking a much more pragmatic approach: they’re shutting down for the hour around the leap
second, just in case. Because in a world where high-frequency trading is dealing in milliseconds,
a sudden glitch in time can really mess things up. [Translating these subtitles? Add your name here!]