Apple addresses 1970 bug, offers new details on triggers, promises fix
Everyone wants a smartphone that’s future-proofed, ready to not just tackle the tasks at hand today, but armed with the processing might, ample storage, and flexible software to put in a good place to handle the unexpected demands of tomorrow. And while that’s well and good, few of us spend much time thinking about whether or not our phones are adequately equipped to handle the past. That sort of oversight found Apple in an embarrassing position last week, as word started spreading of a glitch that temporarily bricked iPhones when users manually changed the phone’s date to the start of the year 1970. This week Apple owns up to the bug, tells us a bit more about how it’s being triggered, and assures us that a permanent fix is in the works.
The initial report we saw mentioned changing the phone’s date to January 1, 1970 as the causative action for these lock-ups – freezes that only found themselves able to be resolved after an affected phone ran its battery down to zero. As the zero-hour for Unix time, the idea of glitchy behavior happening right at the stroke of midnight on that date made enough sense, but it turns out the window that triggers this bug is much broader: Apple informs us that any date from May 1970 or earlier can freeze the phone on its next boot.
Apple says that an upcoming iOS update is intended to resolve this behavior once and for all, but we’re not sure just when that might be; iOS 9.3 is expected to land next month, but it may be too far along in its development cycle to pick this patch up – in which case, we wouldn’t be surprised to see something like 9.3.1. We’ve also heard the theory that Apple could push this one out even earlier as a 9.2.x cycle release.
Again, the best defense against this glitch is simply not to go, really, really out of your way to trigger it in the first place.