datebug
Latest
A possible explanation for the iOS New Year's Do Not Disturb bug
If you've been living under a blissfully silent rock for the last couple of days, it may have escaped your notice that an annoying bug in iOS means scheduled Do Not Disturb periods don't automatically end. Apple's response was a rather weak KB article that amounts to a shrug and a claim that the problem will "resume normal functionality after January 7, 2013." [UPDATE: as pointed out by Liam Gladdy in a comment written an embarrassingly short period of time after this story going live, there's something wrong with the reasoning below. The period of January 1st-6th is actually the first ISO week of 2013, not the last week of 2012, so (at least as written here) the explanation cannot be correct. The bug could be related to the ISO week calculation, or it might not; however the working out in this article is definitely flawed in several ways. The blogger responsible has been taken out the back and shot.] Digging into the problem I did some manual testing by winding my iPhone's clock forward several years and setting different times to turn DND on and off again. You can replicate this easily by scheduling one minute of DND, changing your iPhone's date and time, and watching to see if DND correctly switches on and then off again. If you try this too, note that you'll get some scary-looking warnings about mail server SSL certificates, not having backed your iPhone up for several years, and some nagging about app updates. It should be safe to click through those. To me, it seemed that in the years I tested (2013, 2014 and 2015), as long as the "Enable from..." time set in the Do Not Disturb schedule settings fell after midnight on the first Monday of each year, then it would work correctly. Conversely, I would see wonky behaviour (a technical term, there) until that first Monday. A similar pattern was recorded by MacRumors forum poster "stevem1981," who tested all the way up to 2024. Note that he talks about the "fix date" being Sunday, rather than Monday, because he's scheduling the DND after midnight, as he says in the last sentence. But stevem1981 recorded some weirdness, too; like in 2016, when the bug doesn't occur even though the week starts on a Friday. Or 2017, when the bug happens through as far as January 8 even though the year starts on a Sunday. So it's not as simple as "it doesn't work until the first Monday of the year." More on that in a moment. This is enough information that we can theorise how DND works, and what is going wrong. A possible explanation Firstly, note that the bug is related to DND switching off, not on. The device always moves into DND mode successfully, but never comes back out of it. Secondly, note that the bug occurs when the "Enable from..." time is before the first Monday in the year. That suggests that the way DND works, under the hood, is that when it switches on through a schedule, a timer is kicked off (in some background daemon) in iOS; that timer is responsible for turning DND back off again at the appropriate time. The timer has problems during something a bit like, but not exactly, the first calendar week of the year. Now, to programmers who've done a lot of work with date and time handling (like me; I write airline flight systems for a living, which require a lot of heavy timezone math) "it's broken during something like the first week of the year" immediately suggests a moderately obscure problem related to the ISO week date. This is a slightly weird definition of the year that you get from many date manipulation libraries by specifying that you want the year as "YYYY", as opposed to the more common "yyyy". It's derived from an ISO standard that defines the first week of the year as starting on "the Monday that contains the first Thursday in January". Under this definition, the first few days of the year that we write as "2013" are actually counted as being part of 2012 instead; 2013 doesn't begin until Monday, January 7. It's the sort of thing accountants like to use to keep things neat and tidy. Interestingly, January 7 is exactly when Apple says the problem will go away. Ah hah! So, for 2013, the 1st-6th of January will show as being part of 2012 if the developer specifies "YYYY" in his or her date string, rather than being part of 2013. This means that when DND automatically switches on, it will have a calculated switch off date of sometime in 2012, which is now in the past so it will never turn off. I once made this mistake in my own code, as it's very easy to type "YYYY" instead of "yyyy"; it seems some nameless Apple engineer has done the same in iOS's Do Not Disturb function, but only in the automatic switch off time, not the switch on time part. In my case, the problem was caught in automated testing and never went live. The Apple engineer has been less fortunate. I'm not the only one who is thinking along these lines. iOS dev Patrick McCarron mooted it on Twitter, and MacRumors forum poster "akac" had the same theory. Charles Arthur wrote the story up for the Guardian and linked to a code sample by Chris Cieslak that clearly reproduces the issue using Apple's NSCalendar and NSDateFormatter libraries. Apple's response On the one hand, I feel sorry for Apple. Presumably this issue had gone completely unnoticed until January 1, and even if the fix is merely changing "YYYY" to "yyyy" there's no way it can get a patch written for iOS, run through internal testing to ensure nothing else was accidentally broken, then released to the world before January 7. So all Apple can really do here is say "sorry, but the problem will go away by itself"... whilst also putting a permanent fix into some future iOS release, of course. On the other hand, Apple's response is rubbish. Coming on the heels of high-profile problems with Daylight Savings in 2010, 2011 and 2012 (plus some oddity with Siri), and most recently Calendar.app crashes if you have an all-day appointment on April 1 2013 (link via Charles Arthur), it wouldn't be unfair to describe Apple's reputation for date and time handling as "rather poor." Seeing as how Apple has basically all the money in the world, and seeing as how bugs like this are quite easily caught with thorough unit testing, you'd hope that this isn't the sort of thing that Apple would put in a shipping release of iOS. Having allowed this rather silly bug to slip through anyway, I think the least Apple could offer us was some crumb of embarrassment or apology. I'm not expecting or demanding it prostrate itself with wailing and gnashing of teeth; just suggesting a little bit of humility might not have gone amiss here. Instead we get a Gallic shrug of a KB article that blandly says, in essence, "scheduled DND is broken. Stop scheduling it that way." I think that's a poor show, and an example of how Apple's minimal attitude to corporation communication will end up making this a bigger story than it should have been because it simply irritates people.
