I wasn't going to do another video
about iPhone bugs, but the 1970 glitch that's been going round
is interesting — because it's probably a type of exploit I
haven't covered before. In short: it is almost certainly an integer underflow
caused by the Unix epoch. And if you understand those terms, you don't
need this video. Everyone else: buckle up, 'cos here we go. January 1, 1970 is a special day for computers.
Back in the 70s, when the UNIX system and all its friends were
being originally designed, the programmers needed a simple way to represent
dates and times, without having to deal with all those awkward
human things like days and hours and minutes. They just needed a ticking clock that it was
easy to do arithmetic on. And the simplest way to do that is just a
number, an integer, representing how many seconds had elapsed
since January 1, 1970. And we're still using that. All over the place, in pretty much every computer everywhere. It's generally the best way to store dates
and times, because it ignores time zones and irritating
human things like that.
Now, I've done videos about it before, so
I won't dwell on it, but all you need to know for this is that
midnight at the start of January 1, 1970 — the date in question — is zero. That's the first clue to what's going on.
Clue number two: it only happens on modern, 64-bit iPhones. Now 64-bit refers to how numbers are stored
on the processor. You've got 64 binary digits to play with, instead of the old 32, which means you can… well, you can deal with bigger numbers, down at the really basic processor level, without having to resort to fancy programming
tricks. Changing the phone, and its operating system, from that old 32-bit system to 64 requires
some work, though, so there'll be subtle differences in the code
between the two. And somewhere, this bug slipped in. Now, showing you 64 bits on screen is a bit
tricky, so let's just use four bits to demonstrate
how this works.
0000 is 0. Then you count up in base 2, in binary, 1, 2, 3, 4, until you get to 15. Biggest number you can store in four bits. You can not count higher than that. But what happens if you try? Well, then you get what's called an integer overflow. After 15 comes… 0. It wraps round and you start again, like an
old, analogue odometer on a car. Now, if you've only got four bits, sure, that's going to be a problem: if you've got
64, well, you're only going to get into trouble when you've counted up past 15 quintillion.
It'll probably be fine. Except. If the largest number you can store,
plus one, comes back as zero… what do you get if you do zero minus one? Well, that's called an integer underflow. You can't store negative numbers in this format. If you can drop the number below 0, you won't
end up with -1, you'll end up with it wrapping around to its
That's why, in the original version of the
video game Civilisation, Gandhi was a dick. He started out with an aggression score of
1. And later in the game, it'd drop further, and no-one wrote code to check it didn't drop
below zero. So instead, it wrapped around, became the
maximum possible, and suddenly Gandhi started declaring war
on everyone. Thankfully, only in a video game. Now. There is a version of this format where
negative numbers are allowed, but if Apple were using that, well, they probably wouldn't have this problem. After all, why would you ever have a negative
time value? It's not like anyone's ever going to do something
like set their iPhone clock back to earlier than
1970(!) And you'll note that you actually can't. If you scroll all the way back, the calendar stops at January 1, 1970, at
zero, because someone at Apple went, no, hang on. That's a bad idea. That could cause a problem. So they set the Unix epoch, as it's called,
the zero time, as the limit.
But if you do set you phone's time to near
zero, then somewhere else in the code, there's a
check — maybe it tries to do a battery time calculation, maybe it just runs the math on when the last
call was, or… well, it's something that no-one's worked
out yet. But whatever that check does, it ends up with a time before January 1, 1970, which just should be a negative integer… except it's not. It's wrapped all the way round, it's giving you a date twenty times longer than the expected lifespan of the universe. And I suspect it may not deal with displaying
that date all that well. But whatever it is, it causes what's formally
known as "undocumented behaviour" and informally known as a crash. Now, I should say that, like always when I
try and break down a bug in an Apple product, this
is speculation: it's unlikely they'll ever confirm exactly
what happened, and it was probably a bit more subtle than
And there is another type of binary integer
— it's called a signed integer — that does handle negative numbers… but that's a story for another time. Even if this isn't exactly what caused it? Well, hopefully it'll stop you making the
same mistake in your code in future. [Translating these subtitles? Add your name here!].