Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Ternary

macrumors regular
Original poster
Jul 4, 2015
168
162
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.
 
Last edited:
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.
 
Last edited:
Or Apple could issue a patch that resets the seconds counter. Just sayin'...
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.
 
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.
 
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'.
What do you suppose I'll be able to get for my original first-generation iPhone, still working, in the year 2038?
 
What do you suppose I'll be able to get for my original first-generation iPhone, still working, in the year 2038?
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.
 
I've never owned a phone for more than 10 months (I know, I've got a problem)... so not worried.
 
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.
 
How weird this may sound, I actually enjoyed reading all of that text. Felt like some kind of a short story. xD
I feel like a just read a horror story for nerds. :D
Very entertaining read !

Thank you! What's ironic is that I spent my time writing this instead of my actual English paper. :D


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.

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.
 
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?
 
Last edited:
My Galaxy S4 on Lollipop 5.0.1 won't accept a date beyond Dec 31, 2036. Don't know about other Androids.
 
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.
 
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.
This is actually pretty deadly, they need to fix this ASAP and at least let us be able to DFU restore it or something.
 
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?


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.
 
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?
 
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.


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.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.