After a few days of silence and idiots playing with the Unix gods and bricking their phones, Apple has finally acknowledged the bug that bricks phones with their clocks set to January 1, 1970. Curiously the support document on Apple’s site doesn’t list the well-known January 1 date, but May 1970 instead.
That makes things interesting. While theories started flying immediately that the 1970 bug must be Unix-related, it remains unclear if this is the case for a few reasons—including Apple failing to explain itself. So days after the bug started making headlines we still don’t know what’s happening. Here’s why.
January 1, 1970 is also known as the Unix Epoch. It’s time zero for any device that uses Unix. As in it actually sets the clock to a series of zeroes. It can, potentially, really screw up your device if you roll it back to that point. (See that time Facebook told you you’d known all your friends for 46 years.)
In the case of the Apple bug, it makes perfect sense that the bug might “brick” a phone by throwing it into a never-ending boot loop. All the phone needs to do is reference that date (now all zeroes) and attempt to multiply or divide. Simple mathematics dictate that every process that follows would also zero out. Thus. Boot loop.
The ways to resolve the bug also suggest that this a Unix Epoch issue. Currently, it can be fixed by resetting the internal clock. This can allegedly be done through jailbreaking, but the easier method for most users would be removing the battery or letting the phone run down to 0 percent. That second method can be difficult to do. Most devices shut down at 3 percent to preserve enough juice to maintain the device’s internal clock. So you’ll need to forget about your phone for a few days before you plug it in.
So all signs point to a Unix Epoch bug, right? Well, Apple hasn’t admitted that’s the case. In their notes, they specifically tell users not to set their phone back further than May 1970. Unless someone at Apple is hung up on the Kent State shootings, there’s not a logical reason for that being the cut-off date for phone brickage.
Things are further complicated by the fact that the bricking only reportedly happens in 64-bit iOS devices running iOS 8 or later. 32-bit devices should, theoretically, be subject to the same bug, but so far reports from users on reddit are suggesting they are not. (They are, however, subject to the 2038 bug, which will toast any 32-bit Unix-based device by taking it to the end of 32-bit Unix’s calendar.)
Theoretically, iOS 7 devices should also be subject to the bug. iOS 7 is built on the same framework as iOS 8. However, again, reports are showing that iOS 7 devices remain safe.
While the issue is currently limited to those wanting to test-brick their phone and experience the bug firsthand, all iOS users should be wary. Malicious hacker types with nothing to do on their Presidents’ Day off can actually change the date on your phone by using the feature that syncs the date between your phone and a server.
For now you should hop into your settings, go to General->Date & Time and turn off the “Set Automatically” switch.
We’ve reached out to Apple for further details on what precisely the bug is. For now stick to telling your time manually and wait for an update.
Or scroll that clock back to early 1970. I hear you get a totally cool logo if you do.
Update: Apple has declined to comment.
Contact the author at firstname.lastname@example.org.