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 maximum value.
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 this.
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!]