"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?
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.
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.
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?