The iPhone Alarm Failures of 2010 and 2011, Read Closely

Sunday 7 November 2010 was the day US clocks went back, and Apple’s advice that week was to stop using recurring alarms on the iPhone. Alarms on the phone failed for many users in Australia, New Zealand, Europe and the United States on three separate daylight saving mornings, then again on New Year’s weekend 2011, and Apple confirmed both bugs.

What broke in 2010?

The first bug was about daylight saving time. In iOS 4, a recurring alarm in the Clock app did not follow the clock when the clock changed.

Australia and New Zealand noticed first, when they moved to daylight saving at the end of September 2010. Recurring alarms went off an hour early. Apple acknowledged the problem and said the fix would come with iOS 4.2. New Zealand went first, and parts of Australia followed a week later.

Europe ended daylight saving on the night of October 30 to 31. On Monday, November 1, European users reported recurring alarms an hour late. The phone showed the right time; the alarm did not follow it. Engadget and CBS News both ran the story that week, and the promised fix had not arrived.

Then the United States. Daylight saving ended there at 2 a.m. on Sunday, November 7. CNN reported that recurring weekday alarms would ring an hour late on Monday. Apple spokeswoman Natalie Harrison said: “We suggest customers set nonrepeating alarms for now and reset after November 7 to resolve the issue.” VentureBeat put it bluntly: in the US, you could not rely on your iPhone to wake you on time that morning.

One bug, three regions, three separate mornings, and the software had been known-broken for weeks before the last one.

What went wrong on New Year’s Day 2011?

A different bug, same family. Non-repeating alarms set for January 1 or 2, 2011 did not go off. Reports began on Twitter as time zones rolled into the new year, and 9to5Mac was writing about it on December 31 (its headline: “New Year’s 2011 breaks non-recurring iPhone alarm clocks”).

The affected versions, per the coverage, were iOS 4.0.2, 4.1 and 4.2.1, the newest release at the time. Someone who had done the responsible thing and updated still got hit.

Apple’s statement, from the same Natalie Harrison, as quoted at the time: “We’re aware of an issue related to non repeating alarms set for January 1 or 2. Customers can set recurring alarms for those dates and all alarms will work properly beginning January 3.”

That is the reverse of the November advice. In November, Apple said to stop using recurring alarms and set one-time ones. In January, it said to stop using one-time alarms and set recurring ones. Each workaround was the other bug’s trigger.

The damage was real. MacRumors reported on January 3 that some users still had failing alarms that day, after Apple said things would be fine, and that people said they had missed flights or arrived late to work. Pau Gasol of the Los Angeles Lakers told reporters his alarm did not go off before a shootaround, and other Lakers reportedly overslept too. That is the player’s account of the cause, not Apple’s.

How long did it take to fix, and who noticed?

Users noticed. Every step of this story starts with ordinary people missing something and saying so online. Apple’s statements came after the complaints, and the workarounds were advice to change behavior, not patches.

The timeline, as far as the sources support it:

• Late September and October 2010: Australian and New Zealand reports; Apple says a fix will ship later.
• November 1, 2010: Europe hit an hour late.
• November 7 to 8, 2010: US hit, with the fix still not shipped.
• November 22, 2010: iOS 4.2 released.
• January 1 to 2, 2011: non-repeating alarms fail on iOS 4.2.1.
• January 3, 2011: Apple’s promised recovery date; some users still report failures.

Wikipedia’s article on iOS issues describes the New Year’s bug as seemingly fixed in iOS 4.3. It also came back. PhoneArena ran a story headed “iPhone alarm clock bug rings in the New Year again for users with older iOS versions,” about January 1, 2012. The people caught then were the ones who never updated.

What does this teach about trusting one phone’s alarm?

A phone alarm can fail without any fault in the speaker, the battery or the user, because the alarm is software that decides when to ring, and that software can be wrong about the date. In 2010 and 2011 it was wrong on three daylight saving mornings and on a holiday weekend, and each time the person asleep had no way to know until they woke up late.

The failure was quiet: nothing beeped, nothing warned, and you cannot notice a bug in an alarm from inside the sleep it was supposed to end. It also lived on the edges of the calendar. Clock changes and new years are the days when a wrong wake-up costs the most, because people fly, start jobs and catch trains on them. Which wall-clock minutes a given change removes or repeats is a list you can compute city by city, so a phone has no excuse for guessing.

And the fix was not in the user’s hands. The sensible move on each of those mornings was to stop depending on the broken thing. People with a bedside clock, or a partner with their own phone, lost nothing. Some workplaces already treat one alarm as no plan at all, and in some jobs a late start is grounds for dismissal.

Where does DontSnooze fit in this?

DontSnooze is a social accountability alarm app. Friends see proof, a video, that you got up, and if you don’t, a random photo from your camera roll goes to them instead.

It is also an app on a phone, so it shares the failures in this story. If a date-logic bug in the operating system had stopped the 2011 alarms, an alarm app running on that system would have been exposed to the same class of bug, with no separate clock to fall back on.

Friends seeing proof can tell others you did not get up, but they cannot make the phone ring. A silent phone on January 1 would still be a silent phone, and your friends would learn about it after the fact, the way the rest of us learned about the alarm bug. A second independent witness, such as a bedside clock or a person who will call, is still sensible. Whether a phone rings is a separate question from whether a recorded clip can be waved away, and this story concerns only the first.

Small questions about the big bug

When did iOS 4.2 arrive, and did it fix the November bug?

Apple released iOS 4.2 on November 22, 2010, fifteen days after US daylight saving ended on November 7. Apple’s support note for the bug named iOS 4.1, so US users got through the change without the fix.

Did the New Year’s bug need a patch to clear?

No. Apple’s own line was that alarms would work properly from January 3, and 9to5Mac updated its report to say the problem fixed itself that day. Wikipedia’s list of iOS issues describes a lasting fix as seemingly arriving in iOS 4.3.

Can the same kind of bug happen on a current iPhone?

Nobody outside Apple can rule it out. The 2011 fix reached users through OS updates, and the January 2012 repeat of the New Year’s bug hit people who had not updated, so staying current mattered then. Any alarm that depends on date arithmetic can, in principle, fail on an edge date.

Did the November bug hit only iPhones?

No. Apple’s support note covered iPhone and iPod touch running iOS 4.1, and only repeating alarms made in the Clock app. One-time alarms were unaffected, which is why Apple’s advice was to switch to them until after November 7.