Those of us using Apple's new Do Not Disturb (DND) feature under iOS 6 were met with a surprise when January 1 rolled around this week. Instead of automatically switching off at the pre-scheduled time, the DND switch stayed stuck in the "on" position, therefore blocking phone calls or text messages from making noise or lighting up the device's screen unless the feature is manually turned off.
In what some users see as an odd twist of indifference, Apple appeared to not be too alarmed by this bug, publishing a support document stating the bug would fix itself on January 7, 2013. For those iOS 6 users who don't follow tech news closely (such as, say, your family members), almost a week is a long time to wait for a time-based bug to be remedied, and users may not even be aware of the feature being stuck on in the first place.
Inconvenience aside, numerous Ars readers were left wondering: what's causing this bug, and why will it fix itself on January 7? That's what we're here to answer.
Q: What's causing Apple's Do Not Disturb bug and why will it just miraculously fix itself next week?
Apple has declined to publicly comment on the issue and won't explicitly confirm the reason for the bug. But numerous developers experienced in the complicated world of calendaring have stepped up with their observations and the overall consensus has converged on the ISO week date.
Here's how it works and why it's throwing DND for a loop. The ISO week numbering system uses the YYYY format for the year instead of the Gregorian calendar's yyyy. It then looks at which week of the year it is, and then uses a date digit with 1 starting on Monday. So, for example, Tuesday of the 50th week of 2012 would have been 2012-W50-2 in ISO week format.
The problem comes in when January 1 of the new year ends up falling on a date that doesn't get along well with the ISO week format. The first day of 2013 started on a Tuesday, whereas (as noted by TUAW) the ISO standard expects the first week of the year to start on "the Monday that contains the first Thursday in January." In this case, that would be January 7, 2013.
"Overall, working with dates and times is difficult in the fact that the littlest mistake can be a major issue due to the edge cases," Patrick McCarron, a senior iOS developer at StandAlone Apps, told Ars on Thursday. "This is a common pitfall that happens at the beginning of the new year and lines up with the time when the bug will go away."
Indeed, iOS developer Chris Cieslak has posted a code sample that replicates the problem online, showing that it's something many developers can easily fall prey to.
What's perplexing is that Apple points out this common mistake in its own date formatting documentation for developers. YYYY specifies the week of the year (ISO) while yyyy specifies the calendar year (Gregorian). "In most cases, yyyy and YYYY yield the same number, however they may be different. Typically you should use the calendar year," writes Apple.
Indeed, Apple. Indeed.
But why use dates at all?
So dates are difficult to deal with in the programming world, and problems dealing with the ISO versus Gregorian are widely recognized. But this brings up an even more perplexing question of why Apple is choosing to use dates for DND in the first place; the feature allows users to set specific times of day when it's automatically turned on and off, and there's no calendaring involved from the user side.
"Why a date is checked for a time-only event (Do Not Disturb) is beyond me, but clearly it is," McCarron said.
McCarron said he thinks Apple should only be looking at the time to turn DND on or off without even taking dates into account at all. But if there's an upside to this bug being widely covered now, it could be public awareness. "I'm glad this YYYY versus yyyy issue is getting attention," McCarron said.Â "It bit me years ago on an app and I've seen a few other developers who have noticed the issue as well in their code yesterday."
But because he and other developers have experience wrangling this bug themselves, McCarron doesn't see Apple's perceived slowness to correct the problem as indifference. "It's clear by creating the support doc that they are taking it seriously, but I just don't think they can easily push a code fix to millions of iOS users before it would fix itself next week. I'm sure they are not happy about it, especially with the timing of that new Do Not Disturb commercial that is airing right now," he told Ars.
Apple rolled out this new ad highlighting the Do Not Disturb feature just this weekâ"not exactly great timing.
"It'll be fixed in the next iOS update I'm sure, so it won't happen again next year," McCarron said. "But honestly I think the feature gives all of us a nice excuse to screen our phone calls this first week of the year. 'Oh sorry, my iPhone was buggy and I missed your call!'"