First bug of 2011: iOS alarms not going off?(macnn.com)
macnn.com
First bug of 2011: iOS alarms not going off?
http://www.macnn.com/articles/10/12/31/reports.of.alarm.issues.continue.to.plague.ios.4/
6 comments
"The workaround for this new bug is to set all standalone alarms to recurring after midnight. Tests done by 9to5Mac indicate that the bug will correct itself on January 3rd, but until then readers are advised not to solely rely on alarms set on devices using iOS 4.x."
What, "..the bug will correct itself.."? Color me confused but how do you end up with a "self healing 48 hour bug"? Anyone able to provide some clarity?
What, "..the bug will correct itself.."? Color me confused but how do you end up with a "self healing 48 hour bug"? Anyone able to provide some clarity?
The Zune had a similar self-healing bug at the end of 2008. There was a fencepost error that resolved itself once the internal calendar code no longer thought it was the 366th day of the year. So, basically, a one day bug.
http://www.zuneboards.com/forums/zune-news/38143-cause-zune-...
Obviously this isn't the same bug, but it's fun to see the broken code and speculate about similar sorts logic errors that could lead to this working like normal in a couple days.
http://www.zuneboards.com/forums/zune-news/38143-cause-zune-...
Obviously this isn't the same bug, but it's fun to see the broken code and speculate about similar sorts logic errors that could lead to this working like normal in a couple days.
Speculation: the calendar in the clock app is week oriented. It would make sense to store one-time events as (day of week, week number, year).
January 1 and 2 of 2011 are actually part of week 52 of 2010. So, an event for January 2 2011 would be stored as (7, 52, 2010).
Now all it takes is somewhere else for someone to accidentally use the year of the current date instead of the year of the current week when checking to see if an event is due.
On January 3, which is the first day of the first week of 2011, the year of the date and the year of the week again match, so all us well until January 1 2012. In 2012, the bug will only last for 1 day, as week 1 of 2012 starts on Monday the 2nd.
January 1 and 2 of 2011 are actually part of week 52 of 2010. So, an event for January 2 2011 would be stored as (7, 52, 2010).
Now all it takes is somewhere else for someone to accidentally use the year of the current date instead of the year of the current week when checking to see if an event is due.
On January 3, which is the first day of the first week of 2011, the year of the date and the year of the week again match, so all us well until January 1 2012. In 2012, the bug will only last for 1 day, as week 1 of 2012 starts on Monday the 2nd.
It's really surprising to me that there is another alarm bug. This isn't exactly a tricky subject and should be easy testable.
I'm not sure I entirely agree that it's not a tricky subject (it seems like date bugs show up pretty often in computing and there are a pretty good number of corner cases, plus complications from things like time zones) but it most definitely should not be allowed to happen and it sounds like they need to throw much heavier testing resources at it. As another poster mentioned, this is an issue that messes with people's trust in these very personal devices.
As long as humans are writing the code, there will be cut corners and missed test cases. The attitude the "this is easy" could have been the reason it happened in the first place.
If date and timezone related code seems simple/easy to you then you're using libraries! It's messy and easy to mess up!
And Apple isn't using libraries? Also, the time/date has been correct, just the alarm app failing to activate on time.
It doesn't seem like it is just iOS. I noticed an issue in my conky display this morning.
You should be able to see the bug on a *nix box with:
> date '+%m-%d-%G' # shows up as 01-01-2010
where as the following works fine.
>date '+%m-%d-%y' # 01-01-2011
I guess it's not really a bug since %G is the year of ISO week number, but it would be easy for something like this to go unnoticed until the invalid date pops up.
You should be able to see the bug on a *nix box with:
> date '+%m-%d-%G' # shows up as 01-01-2010
where as the following works fine.
>date '+%m-%d-%y' # 01-01-2011
I guess it's not really a bug since %G is the year of ISO week number, but it would be easy for something like this to go unnoticed until the invalid date pops up.
Android: We are all ready to win, just as we are born knowing only life. It is defeat that you must learn to prepare for.
iPhone: I don't waste my time with it. When it comes, I won't even notice.
Android: Oh? How so?
iPhone: I'll be too busy lookin' goood.
iPhone: I don't waste my time with it. When it comes, I won't even notice.
Android: Oh? How so?
iPhone: I'll be too busy lookin' goood.
Has anything like this happened on Android? I'm an iPhone user, but there are some really facepalm-stupid bugs on iOS that takes away from the platform's image as something polished and perfected.
Yep. Android 2.0 (I think) has a bug where alarms will be delayed while the phone's cpu is in sleep mode. This can mean they go off up to an hour late.
My alarm on CM 6.1 on G1 went off as scheduled this morning. I've never had a problem with late alarms.
These are the kind of bugs that screw with people's trust, along with messed up calendars and call-dropping. This is not okay, and should not have happened.