The iPhone Apocalypse: January 19, 2038

Discussion in 'iPhone' started by Ternary, Dec 10, 2015.

  1. Ternary, Dec 10, 2015
    Last edited: Apr 19, 2016

    Ternary macrumors regular

    Joined:
    Jul 4, 2015
    #1
    UPDATE: After reading this post, here's the follow-up with a 64-bit iPhone.
    _____

    You may have noticed that the latest system time you can set on an iPhone is on January 1, 2038. But why does it have to happen on a time when we’ll probably still be alive? Will we be able to continue using our iPhones 23 years from now? To answer these questions, I researched and conducted an interesting experiment based on I found. Read on to find out what will happen!


    Why the Maximum Date is 2038

    The iPhone keeps the time by calculating the number of seconds passed since January 1, 1970 at midnight GMT. Many iPhones store this particular number as a 32 bit integer, and the maximum possible 32 bit number is 2^31−1 (or 2,147,483,647). This means that after 2,147,483,647 seconds since January 1, 1970 (or January 19, 2038 at 3:14:07 GMT), the iPhone's system time will overflow, at least for the 32 bit devices, causing various problems to arise.


    In other words, the 32 bit (and possibly the current 64 bit) iPhone's world will terminate on January 19, 2038.

    You may be thinking, then why is the maximum date January 1 instead of January 19? That date is probably Apple’s method to prevent casual users from breaking the clock too quickly.


    The Experiment

    To find out exactly what will happen to the iPhone on January 19, 2038, I put my iPhone 5 on iOS 8.4.1 to the test. I set its system time to January 1, waiting for 18 days to see what would happen. For additional fun, I started the stopwatch in the Clock app at the earliest system time (1970) just to see what the clock would look like 68 years later and beyond.

    iPhone2038.PNG
    My three foreseen possibilities of what would happen before the test were as follows:
    • The iPhone would completely crash.
    • The iPhone would continue counting time past January 19.
    • Only the clock portion of iOS would crash.

    From January 1 to January 18, the clock worked just fine without any problems.

    But when the iPhone 5 reached January 19 at 3:00 AM GMT, the first abnormalities occurred. When the iPhone 5 was in sleep mode, iOS automatically froze the clock. But when the device was powered on, the time continued to tick. Fascinating.

    At that point, I figured that my second possibility wasn’t true, considering the iOS developers made some attempt to safeguard the clock. Still, I was determined to reach the very end. To prevent the iPhone 5 from auto-locking, I changed the setting to “Never”. Then I left the room for a few minutes.

    When I came back, the clock must have struck 3:14 AM, but I’m not exactly sure if it did. That’s because the clock started glitching sporadically. For some odd reason, the system time suddenly became 8:48 PM GMT. That’s when I put the iPhone 5 to sleep and re-powered it on. What I saw right after that was rather astounding:

    iPhoneBlank.JPG
    That’s right: The iPhone’s lock screen STOPPED displaying the time altogether! Fortunately, I was still able to view the current system time by swiping into the Notification Center.

    So then I proceeded to unlock my iPhone. I entered my 4 digit passcode correctly, but absolutely nothing happened after I tapped the fourth digit. This meant I could no longer unlock the device. It didn’t completely freeze though; I could still swipe back to the lock screen and swipe again to reenter my passcode. I tried entering the wrong passcode for the heck of it, but instead of telling me the code was invalid, it did absolutely nothing as well.

    Even though I couldn’t unlock my iPhone 5, I wasn’t completely locked out. Fortunately, there’s Control Center which I could use to access a few apps. The stopwatch, calculator, and camera worked just fine. The brightness slider, however, ceased to function. I should have but forgot to test the flashlight and WiFi capabilities.

    After testing enough of that, I figured I’ve came to my conclusion: that the iPhone will still operate but not to its full extent. Little did I know what would happen next when I plugged my iPhone 5 to the Lightning cable…

    *vibrate* *vibrate*
    Ok, that’s normal. That’s what the iPhone 5 normally does once it’s plugged in.

    *vibrate* *vibrate*
    Wait, it did it again?

    *vibrate* *vibrate*
    This ain’t looking good. How about I unplug the cable…

    *vibrate* *vibrate*
    THE WORLD IS DOOMED!!!

    At that point, I reached full panic mode. I had to go to sleep soon, but I desperately needed to halt those vibrations that refused to surrender. My initial instinct was to power off the device, but once I pressed and held the power button, the transparent overlay appeared but NOT the power slider or the cancel button!

    (I would have taken a picture of that, but I didn’t think about it at that given moment.)

    Seriously, if you don’t believe the panicking, think about it this way. The nonstop vibrating iPhone 5 sounded like a ticking time bomb, or at least some emergency alarm. At that moment, it really felt like an apocalypse was happening, that the iPhone would explode dramatically and denounce its demise of existence. And if that wasn’t enough, there was an irritated roommate who was cramming for finals.

    My roommate fled the room to study elsewhere, but I couldn’t just leave the vibrating iPhone 5 behind. Still under panic mode, albeit a bit more controlled, I set my iPhone 5 aside and used my laptop to search up alternate ways to fully power off an iPhone. Please have another way, I thought. Otherwise, I’ll be doomed.

    And sure enough, there was another way to power off an iPhone 5: a soft reset. After pressing and holding the iPhone 5’s power button and home button for 10 seconds, praying it wouldn’t explode on me, the iPhone finally blacked out.

    The room never felt more quiet than ever before.

    After I fully calmed down, I called my roommate to come back. He told me I better not tinker with my iPhone 5 until the next day after finals, which I agreed to. So I put the iPhone aside and got some needed sleep.

    The next day, after my roommate took off for class, I examined the iPhone 5 again, theorizing what could happen if I dared to power it on again. My gut feeling was that it would refuse to boot ever again, unless I somehow manage to get it to DFU mode. Even if I could reach DFU, I’d have to sacrifice iOS 8 and restore to iOS 9.

    So to determine the moment of truth, I pressed and held the iPhone 5’s power button.

    The Apple logo appeared, which was a good sign. What was strange, however, was that while the Apple logo was up, I could see a ghosted version of the system time right when I soft reset the phone. But then the iPhone 5 blacked out, and the next thing it showed was…

    …the lock screen!

    Only this time, is was now January 1, 1970 at midnight GMT. The clock reset itself to safety, and all my data, including iOS 8.4.1, was still in tact.

    What was completely unexpected, however, was that the stopwatch did NOT reset. In fact, it was still able to run!

    iPhoneClock1.JPG
    (The time states 4 PM because I live in the Pacific time zone, which is 8 hours before GMT.)

    Curious, I changed the system time once again to January 1, 2038 just to see if I could double the stopwatch’s time. And lo and behold, it did!

    iPhoneClock2.JPG
    With that, I restored the system time back to normal civilization, thankful that no one was injured during this experiment.


    The Moral of the Story
    • The iPhone 5 or earlier cannot exceed January 19, 2038 since they utilize a 32 bit CPU, NOT because of planned obsolescence.
    • 64 bit devices like the iPhone 5s should in theory be unaffected, as 64 bit integers can store a maximum year of 292277026596, long after the world actually ends. However, they may still be impacted since their max date is also January 1, 2038, meaning iOS might still use 32 bit time on these devices.*
    • You can still use the iPhone after 2038, but you won’t be able to use the calendar app or access HTTPS Websites properly. All dates, such as the day a picture was taken, will be inaccurate.
    • You should probably disable Internet time in 2038 in case something bad happens.
    • If you still have a 32 bit iPhone laying around, you might want to sell it before more people become aware of the 2038 problem.
    • If you want to set the world record for the maximum time on the iOS stopwatch, this is how you do it.

    *If anyone has a spare iPhone 5s or newer and would like to perform the 2038 experiment, please share your observations. EDIT (Apr 19): Already done.
    _____

    tl;dr: Don’t plan on using your 32 bit (and possibly current 64 bit) iPhone in 2038, or bad things will happen.
     
  2. rambo47 macrumors 6502a

    rambo47

    Joined:
    Oct 3, 2010
    Location:
    Denville, NJ
    #2
    Or Apple could issue a patch that resets the seconds counter. Just sayin'...
     
  3. garirry macrumors 68000

    garirry

    Joined:
    Apr 27, 2013
    Location:
    Canada is my city
    #3
    If it'll be so deadly, Apple will release a patch a few years before it'll happen.

    Besides, the iPhone 5 will be so old in '38 people will start burning them all because it's considered 'uncool'.
     
  4. lamborghini392, Dec 10, 2015
    Last edited: Dec 10, 2015

    lamborghini392 macrumors member

    Joined:
    Oct 22, 2015
    #4
    I wonder if windows keeps track of the time the same way, except with 64 bit integer capability?

    If so, is anyone willing to destroy their PC by trying this :D?

    EDIT: Apparently windows uses time intervals of 100 nanoseconds so the max 64 bit value would be reached after ~29227 years. Someone can still try setting it this far in cmd if they want lol.
     
  5. Ternary thread starter macrumors regular

    Joined:
    Jul 4, 2015
    #5
    Which is easier said than done. January 1, 1970 is the established reference date for Unix time, and many other programs like Web browsers use this system. It might be risky to change the reference date since it could cause program incompatibilities.
     
  6. rambo47 macrumors 6502a

    rambo47

    Joined:
    Oct 3, 2010
    Location:
    Denville, NJ
    #6
    They said the same thing about Y2K too. Much ado about nothing. And Apple has plenty of lead time to let developers make the changes they have to in order to get their programs compliant with an altered time counting mechanism. Mostly programs use the time itself, not the actual counting mechanism. Simply changing the reference date from 1970 to 2020 should pretty much solve everything.
     
  7. rambo47 macrumors 6502a

    rambo47

    Joined:
    Oct 3, 2010
    Location:
    Denville, NJ
    #7
    What do you suppose I'll be able to get for my original first-generation iPhone, still working, in the year 2038?
     
  8. garirry macrumors 68000

    garirry

    Joined:
    Apr 27, 2013
    Location:
    Canada is my city
    #8
    If Apple decides to update all old devices to work with a new internal calendar (assuming the whole UNIX environment can do it somehow), then yes. While today, it is very unlikely that Apple will do that, you don't know what will happen in 22 years. Steve Jobs didn't even stay for 15 years between his return to Apple and his death.
     
  9. C DM, Dec 10, 2015
    Last edited: Dec 11, 2015

    C DM macrumors Westmere

    Joined:
    Oct 17, 2011
    #9
  10. iTom17 macrumors 6502a

    iTom17

    Joined:
    Aug 2, 2013
    Location:
    the Netherlands
    #10
    How weird this may sound, I actually enjoyed reading all of that text. Felt like some kind of a short story. xD
     
  11. barkomatic, Dec 11, 2015
    Last edited: Dec 12, 2015

    barkomatic macrumors 68040

    Joined:
    Aug 8, 2008
    Location:
    Manhattan
    #11


    I feel like I just read a horror story for nerds. :D
     
  12. lordhamster macrumors 6502

    Joined:
    Jan 23, 2008
    #12
    I've never owned a phone for more than 10 months (I know, I've got a problem)... so not worried.
     
  13. thewap macrumors demi-god

    thewap

    Joined:
    Jun 19, 2012
  14. ocabj macrumors 6502a

    ocabj

    Joined:
    Jul 2, 2009
    #14
    No disrespect, but to only look at this issue with relation to an iPhone is a bit shallow. The Year 2038 problem with Unix time has wider ranges of repercussions than a phone that will obsolete in 2038. Considering that most software and the libraries they're built on rely on unixtime mean applications, scripts, etc., will need to be rewritten. Then there's issues with embedded systems where such a software fix might not even be available. There's a pretty good chance cars from 2015 and older will be on the road in 2038. It's likely the onboard computers are using signed 32-bit integers for time, which may or may not cause safety issues.
     
  15. Ternary thread starter macrumors regular

    Joined:
    Jul 4, 2015
    #15
    Thank you! What's ironic is that I spent my time writing this instead of my actual English paper. :D


    You are most certainly right. It is definitely a more massive problem than just the iPhone (Android, older Macs, Linux systems, and cars are affected too). It's just that since this is an iPhone forum, I primarily focused the issue on that device.
     
  16. HEK, Dec 11, 2015
    Last edited: Dec 11, 2015

    HEK macrumors 68030

    HEK

    Joined:
    Sep 24, 2013
    #16
    If you still have your iPhone 5 in 2038 you have more problems than the phone time being off. We should be at about iPhone 18 or 18s by that year. And maybe your roommate is right, shouldn't you be studying for mid terms?
     
  17. aKansasKid macrumors regular

    Joined:
    Apr 27, 2015
    #17
    My Galaxy S4 on Lollipop 5.0.1 won't accept a date beyond Dec 31, 2036. Don't know about other Androids.
     
  18. knownikko macrumors 6502

    Joined:
    Jan 9, 2009
    #18
    Man, think of all the problems those crushed phones in landfills are going to have.
     
  19. Ternary thread starter macrumors regular

    Joined:
    Jul 4, 2015
    #19
    Update: If any of you were thinking about trying the 2038 experiment on an iPhone 5s or newer, DON'T TRY IT. You might brick your iPhone.

    I was going to try the experiment with a 64-bit device after I get another iPhone upgrade, but until Apple fixes this system time bug, it's not worth risking another Genius Bar visit to see what happens.
     
  20. garirry macrumors 68000

    garirry

    Joined:
    Apr 27, 2013
    Location:
    Canada is my city
    #20
    This is actually pretty deadly, they need to fix this ASAP and at least let us be able to DFU restore it or something.
     
  21. BeeGood macrumors 65816

    BeeGood

    Joined:
    Sep 15, 2013
    Location:
    Lot 23E. Somewhere in Georgia.
    #21

    Was just about to post this.

    If anyone still has a functional iPhone 5 in 2038 they need to be more worried about the battery exploding or the screen spontaneously shattering, shooting shards of glass into their eyes.
     
  22. rugmankc Contributor

    rugmankc

    Joined:
    Sep 24, 2014
    Location:
    Dayton, Ohio
  23. ross1998 macrumors 6502a

    Joined:
    Jan 10, 2013
    #23
    So is the iTunes the genius bar uses more advanced to restore your phone? Or would they have to replace the phone to fix it?
     
  24. rlhamil, Feb 16, 2016
    Last edited: Feb 16, 2016

    rlhamil macrumors member

    rlhamil

    Joined:
    Feb 6, 2010
    #24
    The problem is worse than that. Even on systems where time_t (the defined type for a system clock variable) is a 64 bit twos-complement signed integer, the routines that convert a time_t (seconds since 00:00:00 1 Jan 1970 UTC) into a humanly comprehensible form (year, month, day, hour, minute, second, possibly with time zone adjustment) cannot handle really huge values, and choke. For instance, the ctime() function, which is supposed to return a pointer to a human-readable string, returns a NULL pointer.

    AFAIK, on such systems, it could be fixed, since a 64-bit time_t is plenty big enough, it's just that the conversion routines can't handle larger numbers.

    edit: while ctime() etc fail well before INT64_MAX, they do get past the year one billion on OS X 10.11 (64-bit) :) . So depending on the system and how recent the version of the conversion routines, the problem may only be of interest to astronomers and a few physicists.


     
  25. Repelle macrumors regular

    Joined:
    Mar 8, 2015
    Location:
    Andover UK / SF CA

Share This Page