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
I was late for work....gee thanks Apple.
I found out you have to delete the needed alarm(s) and the put them back in.
I found out you have to delete the needed alarm(s) and the put them back in.
I'm not making any claims that it is more complex than x software product. You and others are the ones making the claims that this is such a trivial thing that it is unbelievable that it wasn't caught in testing.
Is that how you would program a clock? That it depends on the week of the year and whether or not that week is crossing into a new year, etc? This is NOT a recurring alarm. This is a single alarm. My question is, why was this affected AT ALL by the change from one year to the next, especially since it affected both the 1st and 2nd. Also, this idea that both Saturday and Sunday were part of the 53rd week doesn't really fly since Sunday would have started a new week. At least that is the default behavior on Apple calendar applications.
The way that I would program an alarm would be that it would set the alert for the next occurrence of that time, dependent on the current day and time. So again, what do you think could have causes this odd bug to occur on both the 1st and 2nd?
We're not talking about programming missile guidance systems here. Date programming is trivial. Any programmer would have written alarm functions in their first year at college. It would also be trivial to write a test suite that could trigger an alarm every single second all the way up to 3:14:08 UTC on 19 January 2038 (assuming Unix Time is in use here). Date calculations are trivial, and predictable. That's what is so funny about this second iphone alarm fubar. I just hope that the person(s) responsible for this code isn't also working in the data security team...
.
We're not talking about programming missile guidance systems here. Date programming is trivial. Any programmer would have written alarm functions in their first year at college. It would also be trivial to write a test suite that could trigger an alarm every single second all the way up to 3:14:08 UTC on 19 January 2038 (assuming Unix Time is in use here). Date calculations are trivial, and predictable. That's what is so funny about this second iphone alarm fubar. I just hope that the person(s) responsible for this code isn't also working in the data security team...
A couple of things:
- I agree that writing an alarm function is trivial.
- I agree that writing the test suite might be trivial but actually running it would not. It would take an inordinate amount of time to test all possibilities. And again, this is something that depended on WHEN the alarm was set and WHEN it was set to be triggered. For example, people are finding that if you set your alarm after midnight when it was already January 3rd then the alarm worked that morning. However, if you set it on January 2nd to trigger on the 3rd it did not work.
- Date calculations SHOULD be trivial and predictible but obviously something really strange is going on here to cause this error. I am leaning more toward the earlier poster that said it could be affected by some function call that is external to the clock app.
You can't program the alarm to go off at specific seconds, so we're talking 525,600 minutes a year. If every second you can test a minute, simple True, False test, did it trigger the alarm or not, then it would take just over 6 days to test every minute in a year. Apple releases a new iOS version every year, so if ran the program for 12 days to test 2 years they would be in the clear.
Then filter through the "False" and find out why the alarm didn't trigger. Fix bug, viola, this thread would have never existed.
I would have DEFINITELY done this after the DST bug, and released a fix. No reason a multi billion dollar company couldn't.
Then filter through the "False" and find out why the alarm didn't trigger. Fix bug, viola, this thread would have never existed.
I would have DEFINITELY done this after the DST bug, and released a fix. No reason a multi billion dollar company couldn't.
I missed the only express bus that exists where I live because of this bug, so I was late to work today. Yeah, an alarm thing is minimal, but it does affect people, so while it's a small function, it's a very important small function that people expect to, you know, just work.
I'm okay though, it's just a little annoying, that's all.
I'm okay though, it's just a little annoying, that's all.
The clock app is written by Apple. They have the source code. They surely have an iPhone simulator for this just like you get with Android. It really would be trivial to write a test suite that sets the date, programs an alarm, and tests the result. It doesn't need to be done in realtime
. The program could iterate all of the seconds in a multitude of years in the time it takes to read this response. Maybe they need to follow Google's lead and apply the "beta" tag to their software....annoying, but nothing that wont take 30 seconds to do!
+2 days that were needed to find out exactly what to do to avoid the problem.
Apple should have been able to tell that on Jan 1st the latest after the first reports came out. The chain of responsibility is frighteningly weak at Apple. From specs to coding to testing and to after sales. Failure after failure. Seriously, this company is worth over $300B?
It's not unbelievable for Apple.
Well, it doesn't really matter how I'd program an alarm clock, and a black box testing procedure shouldn't care either. Perhaps Apple made the same mistake you did and thought it was OK for coders to be testers.
I don't know why you assume the UI reflects underlying logic.
Maybe an alarm results in an event registered with the OS. Maybe the "next occurrence" for every single alarm is not registered (there could be thousands), just those occurring in the forthcoming calendar week. So just before Monday 27 December 2010 the calendar app will have acted on an internal alarm to submit the following week's alarms, indexed 2010/53. But maybe any one-off alarms for 1 January 2011 were indexed 2011/1 and weren't submitted.
Any alarm set in the current batch period will be immediately submitted, so won't suffer - or maybe it will, depending on how the check's performed.
The clock app is written by Apple. They have the source code. They surely have an iPhone simulator for this just like you get with Android. It really would be trivial to write a test suite that sets the date, programs an alarm, and tests the result. It doesn't need to be done in realtime
Spoken by someone who has never set up and/or run a software test.
This is a ridiculous assessment of how it might possibly work since most one-off alarms are not set a week in advance. They are set before the person goes to bed. An example of how this error presented itself:
- Date is currently January 1, 2011
- Set the alarm for one minute from now.
- Alarm does not trigger or alert.
Now, doesn't that seem like a really strange bug and one that might not have been caught in normal testing? I'm not saying that they did or did not test the app. I'm saying that this bug was really weird. I have a feeling that it is much more likely that this bug was generated by some API call and not within the app itself.
Wow, what a day, first I woke up late because my alarm didn't go off then as I was calling in late my phone dropped the call because I didn't hold it right... lol.
Have to say that I love Apple products but also have to wonder what is going on with them and their priorities lately...
Have to say that I love Apple products but also have to wonder what is going on with them and their priorities lately...
Apple response fail. You need to stop assuming things. And most of my alarms are set weeks in advance referring to important appointments or whatever. My wakeup is recurring.
Which would fit in with the possibility I gave, "or maybe it will" option. You set the alarm and the app indexes it 2011/1. But the app still thinks it's 2010/53 (perhaps it caches the year/week index and has neither received a batch submission trigger nor received notification of manual time change) in whatever routines are used for submission, so it won't actually submit it to the OS to trigger an event one minute from now.
Who uses a phone as their normal alarm? The volume isn't very loud. I only use mine when I have no other alternative.
Sure this is a bug that would be nice to have fixed and either way I could see it affecting people (and it did), but I'm surprised so many people choose to use an iPhone as their primary alarm. I'd rather launch my old alarm clock across the room in a half sleep than my iPhone...
Sure this is a bug that would be nice to have fixed and either way I could see it affecting people (and it did), but I'm surprised so many people choose to use an iPhone as their primary alarm. I'd rather launch my old alarm clock across the room in a half sleep than my iPhone...
Actually, this would NOT be caught by "black box" testing, since the current date of the iPhone is set automatically. You would specifically have to override the automatic date function to simulate the transition to 2011, then run the alarm test.
Erm, black box testing refers to a lack of attention to the software's internal workings.
It's reasonable for a tester to have greater control of the system environment than the average user would enjoy. In this way he can replicate as many usage scenarios as possible in time and space.
Yeah, and called it quits the day he spilled his tab card deck on the stairs. "Oh, Fudge!"
Last edited: