Earlier this month, iPhone fans and detractors alike were abuzz on technical forums over what seemed to be a rather tricky bug in iOS.
According to the rumours, setting the date on your iPhone to 01 January 1970 would activate a time bomb in the device…
…so that when you next restarted it, it would freeze during bootup.
Even a complete firmware reinstall wouldn’t help, because the fresh copy of iOS would have the same boot-time bug, and a firmware reset doesn’t update the time.
So your phone would continue freezing every time you restarted, even after the firmware “fix.”
You can imagine what some self-styled security researchers took to doing in Apple Stores, just so they could tell their buddies:
Holy s***! It worked. iPad Pro out of commission.
Others, it seems, decided that a rumour like this was bound to be nonsense, and set out to prove it to themselves with a confidence that was as impressive as it was misguided.
All of this raises the questions, “Why 1970? And why New Year’s Day? Is it anything to do with flared trousers?”
We can’t talk to the sartorial question, but we can explain the significance of 1970.
On Unix-derived systems like iOS, the system time is stored as a non-negative integer (that’s fancy talk for “zero and up”) that is the number of seconds since 1970-01-01T00:00:00Z, which is exactly (OK, almost exactly*) when the decade of the 70s started at Greenwich in London.
In other words, midnight on New Year’s Day, 1970, is represented by the number zero in what’s known as the Unix epoch, and timestamps go up from there.
Unix time Conventional date and time ------------- ----------------------------------------------- 0 = 1970-01-01T00:00:00Z, start of the epoch 60 = One minute past midnight 86,400 = Midnight the next day (02 Jan 1970) 946,684,800 = Start of the current millennium (01 Jan 2000) 1,000,000,000 = 01:46:40 on Sunday, 09 Sep 2001 1,234,567,890 = 23:31:30 on Friday, 13 Feb 2009 1,414,213,562 = 05:06:02 on Saturday, 25 Oct 2014 (√2 x 1 billion) 2,147,483,647 = 03:14:07 on Tuesday, 19 Jan 2038 (doomsday time for signed 32-bit integers) 3,141,592,653 = 00:37:33 on Sunday, 21 July 2069 (π x 1 billion)
Bugs involving Unix times of zero have happened before, not least because zero often has a special meaning in computer programs.
As well as meaning “the start of the 1970s,” it’s often used to denote a range of different situations, such as “FALSE” (meaning that an error happened), or “not-yet-used” (meaning something that hasn’t been changed from its default), or “nothing-out-of-the-ordinary” (meaning that an error did not happen).
When one value inside a program can be interpreted in different ways, problems can easily arise, especially when you think that in C programs and Unix shell scripts, zero sometimes means “it worked just fine” and sometimes means “it broke really badly.”
Combine that with a timestamp, which will never be zero unless someone deliberately sets the clock way back in time – something that might never happen during testing – and you have a recipe for a bug that is a zero day, literally and figuratively.
The good news is that Apple will be fixing this problem in the next release of iOS, version 9.3, so that this bricking trick will no longer work.
Apple’s HT205248 article suggests that the bug isn’t limited to a time of exactly zero, but to any time that’s within six months of zero. Presumably, if you keep your bricked iPhone charged up for the next six months so the clock’s still ticking, it will heal itself once the device thinks it’s mid-1970 again.
Better yet, if you have a device that was already bricked by the 1970 bug, you can register for Apple’s Beta program, reflash the latest pre-release firmware version (iOS 9.3 Beta 4), and when you restart…
…your iDevice should have a new lease on life.
[*] Times denoted by Z-for-Zulu are UTC, an absolute measure of time that is not exactly the same as Greenwich Time, a mean solar time. They differ by up to one second, but that’s a story for another timezone.