Posted on 02/12/2016 10:53:21 AM PST by Swordmaker
We’re going to show you how this date trick works to destroy an iPhone so that you can avoid it yourself. Absolutely do not try this yourself, do not set the iPhone clock to January 1 1970 under any circumstances, it will break any iPhone. It will supposedly also brick any iPad or iPod touch as well, so do not try it on any iOS device.
Do not try this yourself, you will ruin the iPhone. That can’t be made more clear, if you try this, you will ruin the iPhone. In other words, do not try this yourself with any iPhone that you care about, unless you don’t mind sending it back to Apple for repair. Doing this will destroy the iPhone and make it inoperable. That means you won’t be able to use the iPhone at all, it will be broken. So we repeat, again, do not try this yourself. Do not try this at home. Do not try this with your iPhone. Do not try this with your friends or anyone elses iPhone. And most importantly, don’t be fooled into trying this by someone else, as there are several ridiculous pranks in the form of various claims circulating on the internet as to what happens if you set the iPhone date far into the past – don’t do it, it breaks the iPhone. This is often referred to as a bricked phone, because the iPhone becomes as useful as brick.
What not to do: All that is required to brick the iPhone is to set the clock back to January 1, 1970. This is done through the Settings app > General > Date & Time, disabling Automatic, and setting the clock manually to January 1 1970. Then, turn the iPhone off and again or force restart it. The iPhone, iPad, or iPod touch is now bricked. That’s it. The iPhone then boots back up and gets stuck on an  Apple logo screen, unable to do anything else. It’s completely stuck and the device becomes unusable.
Don’t do this:
You’ll get stuck on this, the iPhone becomes useless:
This is quite obviously a bad bug, and though it’s unlikely that average users will attempt to set their iPhone clock back to the Woodstock era, there have been various pranks and claims surfacing on the internet that try to trick people into setting their clock way back into the 1970’s. Don’t fall for it.
The embedded video below demonstrates this with a user setting an iPhone clock back to January 1 1970 and then restarting the device, it then gets stuck on the Apple logo and won’t boot further. The device is effectively bricked.
How you should NOT do this video. WARNING TOXIC TECHNIQUE!
Apparently there is one reliable way to remedy this: take the iPhone to Apple for repair. That’s it. Some users report that placing a new active SIM card into the iPhone can make it work again as well, but given the uncertainty of that it would not be advised to rely on the SIM card approach to fix the bricked iPhone. Interestingly enough, the typical method of fixing an iPhone stuck on the Apple logo with DFU restore does not work, which is why the iPhone must be taken into an Apple store to fix.
So, now that you’re aware of this awful bug, whatever you do, don’t try this at home with any of your iOS devices!
:-)
Man oh man....isn't that just about the biggest wish of every guy on the planet? That is, over the age of 60.
You are only permitted to do that after you have worked out the square root of -1.
“You are only permitted to do that after you have worked out the square root of -1.”
Why do you think they call it the “i” phone?
Sorry to hear that...my response if my son fell for this trick...
He’d be sitting and staring at a “brick” for quite a while until he figured it out.
He’s already been warned about the idiots and saboteurs of the www...he learned his first lesson on sidebar ads when he got the FBI virus for clicking on some game link...I didn’t bail him out for quite a few days until he actually needed the laptop for school.
+1. Tell me about it....
We check literally everything we get from a user or outside entity (network, file, shared memory, etc).
Siri no workie. Of course that is the case now.
My pet peeve with young coders. Condition testing is hardly ever a consideration. You clearly learned back when coding was structured and had rules.
One thing I actually did with some commercial software I wrote - kind of as a joke - was put up one of my applications running in normal user mode... Then literally threw my cat onto the keyboard (gently folks). We always say "what if a cat walked across the keyboard?" at any given time... So I found out. ;-)
Exactly1
I cut my teeth on Fortran and punch cards also!
Exactly WHY would the capability of setting a modern device like an iPhone’s date to anything prior to the date of manufacture make ANY SENSE AT ALL? What is the point?
That's why I called it a "Stupid User Trick." It takes a really stupid user to do it after being warned it will brick your iPhone.
Good question. However, the adding such checks on every outside chance of a user doing every possible "Stupid User Trick" would increase the size of the core code to unweildlyness.
I too, cut my teeth on FORTRAN and Hollerith punch cards. I designed and programmed a database for the Emergency Food Bank I founded more than 30 years ago. I designed it so that we could take a person off the line of applicants and sit them down at the keyboard and with two hours training have them do intake interviews. However, it took over a year of my work to "idiot proof" that input process to prevent these people from finding ways to break the database or input garbage. After that year, though, that database ran for twenty years with no issues.
A supervisor could check the input at the end of the day and correct any errors if there were any, usually not. At the end of the month I could check the error log, and usually the number of corrected errors could be counted on the fingers of one hand.
However, for that first year, I was frequently astounded at the ways the users came up with to crash the system and the database or to input errors. . . and of course, by their very nature, they were always ways I had not anticipated. No programmer or designer can anticipate everything, or as a battle planner should realize, "no battle plan survives the first contact with the enemy!"
Same here, I used to do FORTRAN code on punched cards. Later, it was great to use time-sharing terminals for COBOL, easier to correct mistakes than wait for a punch machine.
Speaking of conditions that shouldn't happen, but can... I was entering code on a terminal in the shared terminal room, busy with a dozen people working away. A gal I was supervising was at the other end of the row, when she screamed out to me
"... I'm missing my period!".
I turned crimson red while the other guys laughed their heads off at me. My wife didn't laugh when she heard about it... ("Honey, it's COBOL!").
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.