yeah, this happened for me too -- I set it for 5:00 AM and it didn't go off, woke up two hours later...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iPhone Clock Bug Prevents Alarm Triggers after New Year's
- Thread starter MacRumors
- Start date
- Sort by reaction score
yeah, this happened for me too -- I set it for 5:00 AM and it didn't go off, woke up two hours later...
Add me to the chorus of alarm not working this morning. This is pretty embarrassing that a simple alarm function quits working because of the new year, didn't happen before. And here my wife thought I was just being lazy this morning sleeping in.... thanks for putting me in the doghouse Apple!
would give some better guidance on how to resolve this problem because waiting until Jan. 3 didn't work.
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5)
I had my one time alarm set up for the normal time and a recurring set up for a bit later and both alarms worked just fine this morning. As for all you complaining that yours didn't go off today and you already knew about the bug, get over it. Even if they said the 3rd why would you trust it? You knew the work around Apple gave and chose not to use it.
I had my one time alarm set up for the normal time and a recurring set up for a bit later and both alarms worked just fine this morning. As for all you complaining that yours didn't go off today and you already knew about the bug, get over it. Even if they said the 3rd why would you trust it? You knew the work around Apple gave and chose not to use it.
My alarm did not go off this morning. I only had a one time alarm set. Fortunately, because of this blog post, I was concerned I might oversleep so I naturally woke up at 8 AM and was able to get myself out of bed without an alarm. But I have to say, this seems like an odd, random thing to have a bug with. In this day and age, Apple can't manage time equations in applications?
Set an alarm for 6:30am and guess what.......didn't go off. Everyone said the 3rd, the 3rd, everything will fix itself on the 3rd. I only woke up 15 minutes later though and should have set an alarm on my clock instead.
Here is what i did to fix the issue.
When i set the alarm last night i used an existing alarm but just edited the time, so the alarm didn't go off. I then deleted all my existing alarms and started fresh and it worked. I even edited the new alarm and it still worked. Try that.
Here is what i did to fix the issue.
When i set the alarm last night i used an existing alarm but just edited the time, so the alarm didn't go off. I then deleted all my existing alarms and started fresh and it worked. I even edited the new alarm and it still worked. Try that.
Posted by someone that has never written, tested, or debugged software in their life. A lot of things are only a line or two of code when it comes to fixing them. The problem is that you first have to know there is a problem. But I suppose your test suite for the alarm clock would be to test every possible alarm scenario on every possible day for the next five years or so?
Exactly.
Finally, the voice of reason from someone that has never even written software. Why is your observation not obvious to everyone else posting here? It isn't about how small of a bug it is. It is about how hard it would be to realize the bug was there in the first place. Kudos to you for looking at this logically.
What a crock. Snow Leopard is the best version of OS X hands down and I've been using it since the public beta 10 years ago.
Effin' this. There was a work around people, why is everyone so bent out of shape about this? My alarm didn't go off this morning, but I set a recurring one for five minutes later, because I had a feeling when they said the 3rd they meant you had to set them today. Guess what? I woke up.
It's not rocket science, here.
Deleted all alarms, then set two new ones a couple of minutes apart, one repeating and one normal. Only one of them worked.
Annoying. Seriously, how hard can it be to implement this?
Not that I trust a single source of alarms for waking up if it is something important, but my iPhone can't currently be used even for day-to-day reminders which makes it less usable than it is supposed to be.
Annoying. Seriously, how hard can it be to implement this?
Not that I trust a single source of alarms for waking up if it is something important, but my iPhone can't currently be used even for day-to-day reminders which makes it less usable than it is supposed to be.
I've written a lot of software, and yes you test for cases just like this. Writing an alarm clock is first or second semester software engineering. It's basic stuff. Same with testing for boundary cases.
The more little things like this slip through the more I wonder what bigger problems there are behind Apples shiny veneer. If they can't properly test and fix the clock.app how they can be expected to properly implement security?
It's called edge cases. It's a fundamental piece of software testing. You always test on the boundaries of something, because that's when things are more likely to screw up. Apple should be testing alarms on the first and last day of the year, as well as on the beginning and end of daylight savings time, and in leap years, February 29th and March 1st - at the very least.
You don't even need fancy automated testing for those boundary cases I listed above - those all can be tested in an hour by one person.
And yes, I have written, tested and debugged software at some point in my life. I do it for a living. I was doing it 2 minutes ago before I came onto MR for a quick break.
Give me the reason why you think the alarm failed and why the change from one year to the next is an edge case since this is so simple.
Please, give me the scenario where the automated test would be set up for this. Throwing out things like "Welcome to automated testing" sounds cute but start thinking about what you're saying. Do you have any idea how in depth of a test we're talking about to test all possible scenarios.
In my opinion the software itself should have been written in such a way that it would not have been complex enough for an odd bug like this to crop up in an alarm clock app. However, that is obviously not the case. Barring that I'm genuinely curious as to how easy you think it would be to set up an automated test to test for this. This reminds me of the Microsoft Excel bug from a few years ago. It was something that no amount of testing was likely to ever find. http://www.joelonsoftware.com/items/2007/09/26b.html
Why do you consider the beginning and end of the year to be edge cases? What do you think is being done in the alarm code that the change from one year to the next could cause such a bug? I'm honestly curious about this. Because it seems like a completely innocuous event from a clock standpoint since most time is calculated from the UNIX Epoch in computers anyway and only later translated into days, months, and years.
My alarm went off this morning, so for that I'm grateful. Luckily my biological clock would have saved me even if it hadn't worked. Apple, you've made quite a mess.
I have no idea to be honest - if they are using the UNIX Epoch it really shouldn't be an issue. My guess is they're not using Epoch. Or they are using Epoch, or there's a bug in the conversion from what the user inputs in the friendly, readable format to the Epoch. We deal a lot with timestamps in the software I write at work, but unfortunately we don't use Epoch which has caused many problems (We interface with multiple systems from all over the company, so it's some Oracle timestamps, some XML timestamps, and other formats depending on where it comes from, a real pain in the ass). But Epoch or not, I would test the beginning and end of year just to be safe.
I can officially say I have *not* been bitten by this bug. I use my iPhone as my alarm clock every day, and have been woken by it every morning since the new year without fail. (Except that on Sunday I turned it off and went back to sleep because I didn't need to be anywhere.)
The obvious way of picking this one up would be a group of tests which set time to before obvious boundaries and make sure that the alarm is triggered after the boundary. Speeding up wall time would probably be part of any time-sensitive test suite, but this bug was so trivial that even a basic set of manual tests would have highlighted it.
The only thing more worrying than Apple's not picking it up is iPhone users being so uncreative that not one messed around with his 'phone enough to discover the problem. I'm sufficiently geeky that I often try to see how anything time-y I get behaves in leap year February or at year end. But the suggestion is that Apple knew but deliberately did nothing about it.
No, I don't. You obviously do, so please tell me what about testing an alarm clock is so incredibly complex vs all other consumer and industrial software you, I and anyone else have worked on.
This is black box testing. Precisely what you don't do is think "oh well I am smart and know how this probably works under the hood so I'm going to skip that case". Indeed, any significant software project has black box testers who are probably more familiar with the users and the problem domain than you but don't really have many/any programming skills.
To actually answer your question, and assuming all the underlying calendar routines are working properly, perhaps it might have something to do with the alarm software treating some 7-day period crossing the new year as week 53 of the past year (when the alarm is set) or week 1 of the next (when identifying upcoming alarms). Who knows? I only have to use Windows iTunes to know that I don't have Apple Developer logic.
