The potential repercussions of changing an available setting on the phone that simply deals with the date and those of speeding in a vehicle aren't even in the same league to be analogous, let alone similar.
Sounds like there wasn't much to what you laid out after all. No problem.
I do it all the time. We create event apps and have to "go back in time" to test a new feature.
And there *IS* the problem. This "bug" was in the system undoubtedly from Day 1 of the iPhone's release (and by extension, iPad's release). That's from 2007, when phones were not ubiquitous and being given to kids. As such phones became ubiquitous, with users requiring all kinds of things, programming the phones most certainly moved out of the hands of a few coders who knew all into the hands of many specialists. Rather like the difference from the days when you'd go to see one doctor for all your problems (eyes, skin, heart, abdominal pain), and now go to specialists.
And why should they have been looking for this over other problems that were a bit more important? Like being able to lock the phone, text, download apps, securely use Apple Pay, etc.? Hindsight is 20/20. You really can't say "they should have seen that mole and been ready to whack it" unless you saw that it was going to pop its head up back when, yourself. In which case, why didn't you warn them? 
Because it only affects 64 bit iOS devices which have only been in existence for that long
I am unsure if this was meant to be a response to me, or the general tone of the thread. I am not flinging stones at developers or asking them to see into the future. I was merely stating that this is NOT something we should be blaming the end user for, as so many people are doing. Apple is fixing thier mistake. Good on them. No sense in calling users "stupid" and "idiots" (as people, not you, have done here).And there *IS* the problem. This "bug" was in the system undoubtedly from Day 1 of the iPhone's release (and by extension, iPad's release). That's from 2007, when phones were not ubiquitous and being given to kids. As such phones became ubiquitous, with users requiring all kinds of things, programming the phones most certainly moved out of the hands of a few coders who knew all into the hands of many specialists. Rather like the difference from the days when you'd go to see one doctor for all your problems (eyes, skin, heart, abdominal pain), and now go to specialists.
If that's the case, which programer, EXACTLY, was supposed to see this buried issue, that original programers hadn't viewed as a problem, and wasn't a problem, and rooted it out on the speculation that it would be a problem?
Exactly how far into the future should programers in the past have seen, and exactly how deep into code written in the past and working just fine in the present should programers explore for hidden bugs? And how prescient do they have to be about what people might do with a product? That's certainly the magic of Apple, that they often see uses for their products that others don't AND that others see uses they don't--which helps the company develop the product further. But that's the problem as well. People will do stupid, and very unforeseen things with such products. So long as the company takes care of them when they DO become a problem, then I don't see a reason for blaming the company for not being able to whack every mole before it pops its head up. People losing their phones and their information, THAT was a real issue (remember this: http://www.cnet.com/videos/wwdc-2009-new-app-helps-users-find-iphone/). This little prank is nothing by compare.
So. Why is everyone raining dow curses on current programers for not rooting out this old bug that the original 2007 programmers hadn't the imagination or foresight to view as being an issue come 2016?
Exactly! If doing this didn't brick-up phones before, then why would anyone working on the 64 iOS worry about it? Why would it occur to them that 64 bit would do this? Especially when those programmers are focused on fixing bugs in really important programs like Apple Pay, not sweeping the old, less important stuff (that seems to work fine) for potential bugs that are unlikely to occur. In short, the programmer would have to (1) think of manual date setting in this iOS (which they might not), (2) they'd have to see that 64 bits, as compared to 32bits, would cause a problem if someone sets it to 1/1/70, AND (3) imagine that enough people would do this to make it a big deal.Because it only affects 64 bit iOS devices which have only been in existence for that long
Ah, yes. I see. In that case, I misunderstood, and you have my apologies.
[doublepost=1455679681][/doublepost]i was curious if this was fake or not, so i did set my iPhone 6 to 01.01.1970. It was true, my phone got bricked and got stack on the apple logo and didn't move.
Apple has officially acknowledged the "1970" date bug affecting 64-bit iPhone, iPad, and iPod touch devices. The support document does not identify a current fix, but Apple said that an upcoming iOS software update will prevent the issue from occurring in the future.Manually changing an iOS device's date to January 1, 1970 results in a continuous reboot cycle, effectively bricking the device. Restoring through iTunes in DFU Mode also does not appear to work.
Apple has not provided a reason for the bug, but YouTube video maker and programmer Tom Scott speculates that setting the date close to January 1, 1970, which is 0 in Unix time, may be resulting in an integer underflow -- in this case, a date prior to January 1, 1970.
iOS then handles the underflow by returning the negative integrer to the maximum value, which Scott says results in a date that is some 20 times longer than the universe is expected to last. Scott believes iOS may have difficulties handling this large number, resulting in affected devices crashing.
German website Apfelpage.de shared a second YouTube video showing that opening an iPhone and resetting its battery could fix the problem, but this method could damage your smartphone and void your warranty if done incorrectly. The safer option may be to visit a Genius Bar or contact Apple Support online or by phone.
iOS is a Unix-based operating system, and Unix time starts at 00:00:00 UTC on January 1, 1970. Apple does not allow you to manually set your iOS device to a date prior to then, likely in an effort to prevent a bug like this, but changing the date to May 1970 or earlier still causes issues on 64-bit devices.
Article Link: Apple Will Fix 'January 1, 1970' Date Bug in Upcoming iOS Update
Ennjoy
[doublepost=1455679681][/doublepost]i was curious if this was fake or not, so i did set my iPhone 6 to 01.01.1970. It was true, my phone got bricked and got stack on the apple logo and didn't move.
so i connected my phone to my pc, entered my phone to DFU mode and tried to restore it through iTunes without any result.
But after a few phone calls i managed to fix this bug in no time. Very easy and simple. you just have to be careful and have a little knowledge on phones before u do it yourself
unscrew the bottom screws on ur iPhone and open it in half. next to the battery there's like a cover with 2 screws. if u unscrew them and take the cover off, that's the battery cable that connects to the motherboard. with a plastic screwdriver just flip the connector and remove it for 5-10 seconds and then just put it back. screw everything back and ur back to normal !
Problem solved easy. If any other stupid people did brick there phone and haven't found a solution here it is !
Peace
Why? Why should changing a simple setting like the date cause anything even close to what actually happened?
The microwave comes with instructions saying only to put food in there. And, by the way, nobody would ever hire a software engineer who blames the user for a bug. It's not just the users you're worried about; it's attackers. Apple is fixing it like they should.
Yeah, I'll bet the internal clock gets far away enough from 0 if you leave it for some time.
