Slashdot Mirror
iPhone Alarms Hit By New Year's Bug
An anonymous reader writes "Non-recurring iPhone alarms stopped working on January 1 for devices running iOS 4.02, 4.1, and 4.2.1. Apparently, it will fix itself by January 3, and the current workaround is to set the alarm to repeat. My girlfriend wasn't impressed, sleeping in, and I wasn't either, having to race her to work!"
Day light saving errors, new year errors, do they just have crappy coders at apple?
There is no alarm clock more reliable than the human wang
Interesting theory Julian.
http://michaelsmith.id.au
I started using my phone as an alarm clock after discovering that although a backup battery will allow a regular alarm clock to keep the time through a power failure, the alarm will not ring if the power is out at the time of the alarm.
That's probably the sort of thinking that resulted in the bug in the first place. Dealing with time zones and daylight savings issues and the goofy calendar is a big pain in the ass. It's easy to get it subtly wrong. I doubt there's a programmer alive who hasn't made at least one mistake in dealing with time and dates.
I suggest we adopt a 12 month 30 day calendar, with a five day holiday at the end of the year (six days for leap year.) And no friggin' daylight savings.
We've gotta nap for that!
What's to excuse? Bugs happen, they get fixed.
Two points here.
First of all, it's not the first time a stupid but major bug is found in iOS alarm app.
Second, it's a major issue. Alarm not going off at the right time is a bug that would be classified as "critical" under any sane categorization system - it's the most basic, fundamental function of the application not working properly. Even worse, alarm is by its nature a "mission critical" app - unlike most other stuff, which is annoying but mostly harmless when it fails, this one really trips you up. Consequently, it should be heavily tested.
And this leads us to another issue... these kinds of bugs, both this one and the one back in November, show that unit and functional testing coverage of the alarm app in iOS is really horrible. I mean, DST change and year change? It's some of the most obvious and basic corner cases that you write tests for, especially in an application that specifically deals with time! It's practically textbook stuff, or an interview question for QA position. And so it's extremely surprising when that kind of thing goes wrong in production.
never mind that not every CS degree makes you a programmer
No CS degree makes you a programmer. They make you a Computer Scientist.
Proper testing is a function of Software Engineering. This isn't some nitpick: they're completely different fields that both happen to often involve computers, and are frequently confused by many people who go to school to learn CS when what they really want is to be a programmer.
This is exactly the kind of bug I'd expect from someone with a CS degree, fresh out of college and working their first SE job.
Oh, really? Relying on a phone for one of its simplest features is "inexcusable"? Mobile phones have been able to do this reliably for more than a decade. It's practically an Apple-only problem: for everyone else, it "just works".
But yeah, let's blame the victim.
Again, what if this was Microsoft, and Zunes stopped working because of leap year related issues. Would you have excused them? Or would you have posted "I have to wonder why MS's quality assurance department (don't laugh, they must have one) didn't try setting the clock ahead to see what happens?"