Speaking as a programmer, one of my jobs is to ensure users cannot either accidentally or deliberately enter values that break the systems I develop. I would in fact say that checking and validating user input is probably the most time consuming part of development as you have to anticipate and mitigate so many different scenarios.
So while it is clear this bug takes quite a lot of effort to trigger it is Apple's fault for not protecting against it, especially since it can brick your device. If someone else gets hold of your iDevice and manually changes the time or if someone spoofs an NTP server and sends your device a fake time it shouldn't result in a broken device. The system should detect an valid value and reset to a safe default.
Agreed that part of a designer's job is to idiot-proof. But as others have noted, it's not always easy to anticipate every possible permutation of idiotic/accidental behavior. It's monkeys-with-typewriters. And every so often, the monkeys come up with a new one.
"Should have anticipated" is an easy (and common) judgement to make in hindsight. And as was once said over 2,000 years ago, "He who is without sin may cast the first stone."
Now, it's your job to guard against users entering values that would "break the system that you develop..." just how do you know what values will break the system? Do you take the time to research the physical limits of every input; do you refer to a table of system-breakers; or do you do it mostly by the seat of your pants, based on your years of knowledge and experience? But in the end, "guard against" does not mean you will be 100% successful in those attempts.
At one point in my career, the Director of Engineering and I (I was #2 in the department) had to report to a
pair of vice presidents (VP of Operations AM station, VP of Operations FM station), each of whom was a candidate to become President and General Manager. Something would fail at AM or FM, and
both would come storming down the hall, in the midst of the failure, while we were trying to troubleshoot, and demand to know how we could "make sure that this never happens again." "How about, let us get the station back on the air, then we can talk?" In one particularly memorable case, the failure was due to earlier, mandated attempts to "Make sure this never happens again!" It turned out to be one of those, "Just what are the odds?" combination of rare conditions. If the odds had been calculated, the question would have been, "How far to the right of the decimal point do we have to go before we say, 'enough'?"
For decades, coders knew that there would be a problem on January 1, 2000. They'd been truncating dates, intentionally, for all that time. Or, well, some knew it, others may have gone along with a convention established by their predecessors. "Continue using this date format, because we don't have the time, money, or management mandate to change it throughout our system. Besides, there's no way in hell these systems will still be running at the end of the century."
