Apple has decided not to disturb its faulty Do Not Disturb (DND) function on its iOS 6 software. Instead, it has told users that they should wait until 7 January 2013 - when the bug will resolve itself without any further action.
That has left people puzzled as to how Apple is sure the fix will happen (though it can be confirmed by changing the date on the phone). But some developers now reckon they know the cause, which lie in its interaction with the Unix operating system that underpins iOS.
One of the most intriguing suggestions, from iOS developer Patrick McCarron, is that 6 January 2013 marks the last day of the last ISO week of 2012.
The "DND" bug affects users who have scheduled the function to come on at particular times of day or night. When enabled, owners of devices running iOS 6 would be unbothered by phone calls, email and text notifications except from a select group of people they nominate.
Until 31 December, DND could be scheduled to come on and turn off for a set period during the day or night.
But since 1 January, the scheduling system has failed.
Apple has now acknowledged the problem, putting up a support document which baldly states:
Do Not Disturb scheduling feature will resume normal functionality after January 7, 2013. Before this date, you should manually turn the Do Not Disturb feature on or off.
Why that date? Apple has given no explanation. But as McCarron explained on Twitter: "f you use a [Unix] date format string of YYYY (vs yyyy) you get 2012 until Jan 7 when it becomes 2013. Easy mistake to make, I have."
Matt Drance, a former Cocoa evangelist at Apple, pitched in - suggesting that the problem lies somewhere between the Unix codebase and the DND timing system itself. (iOS is based on BSD Unix, whereas Android is based on Linux, which is a different "flavour" of Unix, and may explain why Android phones aren't affected by similar bugs.)
"This sort of thing is almost always a lost translation between user-selected date+time and UNIX timestamp," he said, adding that "Without seeing the code it's all uninformed guessing based on mistakes [one has] made in the past". Date programming, he added, "is really hard."
McCarron's explanation requires a little explanation itself: the "YYYY" format is a Unix-style date formatting which gives the full four-digit year. But it is ISO-based.
ISO weeks, as the Wikipedia entry explains, work so that "The first week of a [ISO] year is the week that contains the first Thursday of the year. It is also (equivalently) the week containing the 4th day of January."
Chris Cieslak, another third-party iOS developer, provided a working example of code that would go wrong in precisely the same way, and posted it on GitHub. He said that if code like his example were used, and the DND turned on during 31 December 2012, it wouldn't try to turn it off until 1 January 2014 - a year later. The fits with the experience of people who found that DND functions enabled on 31 December 2012 didn't turn off on schedule on 1 January 2013.
Another user test discovered that the fault will resurface unless fixed again and again around the new year of forthcoming years, but on different days - reinforcing the belief that its cause lies in a year-encoding problem.
In 2014, for example, the bug will persist from 1 Jan to 4 Jan; in 2015, from 1 Jan to 3 Jan. "If DND is scheduled before midnight, then the issue and the fix (see above) are delayed one day since it's based on the From time under Scheduled," said the tester, posting on the Macrumors forums.
Apple would be expected to fix the problem before then. Although an upcoming update to iOS 6, v 6.1, is not thought to fix it, a complete update to iOS, version 7, is expected some time in the autumn. The question now is whether Apple will audit the iOS codebase to find and remove other bugs that will cause similar problems.
Apple has previously had problems with date-related bugs. In November 2010, its iOS 4 software failed to readjust alarms to allow for the Antipodean change in Daylight Savings Time - a problem that was then repeated in the UK and the US a few weeks later.
And on January 1 2011, its iOS 5 software turned up a bug in which non-repeating alarms set before the new year didn't ring. Apple's reaction then: wait for 3 January.
