The Do Not Disturb feature was added to iOS 6 in order to silence what might otherwise be distracting notifications, like those during a meeting or while sleeping. Users can manually turn Do Not Disturb on or off, or can set a scheduled time for Do Not Disturb to kick in automatically and then reset later. For instance, many users set Do Not Disturb to turn on around bedtime and reset the following day.

However, users discovered on January 1 that Do Not Disturb did not automatically reset as scheduled. Furthermore, after manually resetting, it wouldn't engage as scheduled that evening.

We contacted Apple when the problem still had not sorted itself out on Wednesday morning. A company spokesperson declined to comment specifically on the cause, but instead pointed us to a knowledge base article published on Wednesday afternoon.

According to Apple, "Do Not Disturb scheduling feature will resume normal functionality after January 7, 2013." Until then, iOS 6 users are stuck manually turning Do Not Disturb on or off as needed.

69 Reader Comments

Now, does anybody know what is the reason for this weird behavior? iMO, it should not be so hard to make it think “if it’s 22:00 local, enable DND; if it’s 6:00 local, disable DND.” Does it require so much magic? I don’t think so.

Dates and Time are inherently complex. Anybody who has tried to build a system that adjusts for leap years can tell you that getting all of the corner cases correct is a non-trivial task. Add time zones, leap seconds, ancient hacks to handle the Y2K bug, and the whole am/pm thing on top of that and it's a lot more complex than people realize.

You can use system libraries to push the problem off on someone else, but then of course you're screwed when they mess it up. Even then it's certainly possible to mess up when you're using an API too. It's easy to get messed up because the API returns the hours, minutes, seconds, years, and days of the month like you would expect, but then numbers the months from 0 instead of 1, causing your program to always be a month off. That's a fairly common bug. Another favorite is the year function returning wildly different results based on how close your result is to the year 2000. So if you ask for the year "98", it assumes you mean 1998, but if you ask for "55" it assumes you mean 2055. Obviously the best solution is always work with 4 digit dates, but sometimes that's not possible for one reason or another.

Didn't Apple have Date/Time bugs before in their products quite recently? What is it with Apple and dates and times?

There was a recent Android bug that completely nuked the month of December. Thinking of that, maybe?

I was about to lay into Apple because yes they've had problems like this multiple times! At least twice (the latest problem was mentioned in a previous comment). However, this gave me pause. Now I just want to know more about the structure of both systems to understand why this happens. Why is so hard to nail down scheduling systems? This is even more important on phones than PCs, because we all carry around phones as our reminder tools. Obviously iOS is not doing enough end of year stress testing and there's something about the scheduling tools that they can't or do not test as of January 1st of the next year. Neither Apple nor Google should be letting things like this happen.

PS I'm an Apple user so I wasn't about to launch an anti-apple bashing comment.

It's easy to flub date related programming if your logic isn't insightful enough, or you pick a poor methodology (like eschewing the use of a well tested library) for doing date comparisons and related data modeling/serialization. You'd be surprised how frequently it crops up. It's not exactly hard to do right, if you pick the right implementation from the start, but fixing a poorly implemented date handling method can get costly if it's pervasive. Foreseeing or knowing all of the pitfalls, using the appropriate libraries/functions, and architecting the related logic correctly is where a lot of people seem to have trouble. It's not hard to do it right, but it can be difficult (or at least require more thought than many want to apply to date routines) to know which way is doing it right, basically.

Quote:

You can use system libraries to push the problem off on someone else, but then of course you're screwed when they mess it up.

That's entirely fair (of ANY library, really) but the alternative means you have to re-do a lot of work, for something that has often been fairly heavily QA'd and often bug fixed if it has been live for some time (even if only simply by dint of having passed through so many hands and circumstances). Dates (and related, like datetime) are especially something where I've almost always seen the alternative lead to more tears than otherwise. Personally I'd rather build on (and override) a library that mostly works than try to do it from scratch, even if there were known issues.

That's the great thing about Apple products. They just work... or they don't.

Yep actually I agree with this. Apple stuff often has limited or no user interface, thus when things don't work you have nowhere to go troubleshoot or figure out why. Great when it works, crappy when it doesn't.

This is one of those times I wish Apple was more open. I'm very curious as to why Apple time systems seem to always screw up in the New Year and why DND will suddenly start working again January 7th. I recognize the above statements about how working with dates can be hard, but for Apple to be able to say a specific date to when it will magically start working again, they must know something, and with all the January-related problems, I question this being a "corner case" that couldn't be picked up in QA testing.

I had noticed this morning that my iPhone was still in DND mode an hour after it should have stopped, but since I don't get that many phone calls and they end up going to VM most of the time anyway, I didn't worry too much about it - that said, I'm glad I saw this story as it explains what happened.

Mother fucker. That's why I haven't been getting message notifications. I'm so stupid I didn't figure it out. And like FXWizard I did notice that the crescent moon indicator but didn't think much of it until I read this.

[Now I just want to know more about the structure of both systems to understand why this happens. Why is so hard to nail down scheduling systems?

It's relatively easy to work with absolute dates, there your only real complication is leap seconds which appear unexpectedly.

However, life gets much harder when you need to deal with relative dates. Such as "turn DND off at 8 AM". What if you change timezones between now and then? Or you enter or leave daylight saving time? Adjust the clock? Or the system is powered down before 8 and turned back on after?

One way to do this is have the system notify you at some predetermined absolute time, then look if it's time to do something, or go back to sleep again. If you make a wrong choice with that "wake up and check" time a bug like this can be the result. Alternatively, the system could trigger an action when the difference between UTC and local time changes. In this case, you'd want to make an exception for year changes, which could then again trigger a bug like this.

The thing is, Apple was bitten by this type of stuff before and STILL didn't test properly. They can't keep doing this forever, a backlash against their poor software quality practices will happen at some point.

Now, does anybody know what is the reason for this weird behavior? iMO, it should not be so hard to make it think “if it’s 22:00 local, enable DND; if it’s 6:00 local, disable DND.” Does it require so much magic? I don’t think so.

Steve Jobs didn't want to be disturbed while recuperating from New Years.

Didn't Apple have Date/Time bugs before in their products quite recently? What is it with Apple and dates and times?

Similar to Google losing December in Android. All vendors have bugs.

Except that that's not what happened, but your history as an Apple water-carrier is well-known.

Android had an off-by-one error in a dialog in a rarely-used feature in a peripheral application (I've literally-literally never tried to set a birthday on a contact). Apple has "lol, new feature doesn't work."

You can use system libraries to push the problem off on someone else, but then of course you're screwed when they mess it up.

That's entirely fair (of ANY library, really) but the alternative means you have to re-do a lot of work, for something that has often been fairly heavily QA'd and often bug fixed if it has been live for some time (even if only simply by dint of having passed through so many hands and circumstances). Dates (and related, like datetime) are especially something where I've almost always seen the alternative lead to more tears than otherwise. Personally I'd rather build on (and override) a library that mostly works than try to do it from scratch, even if there were known issues.

The fact that iPhone date bugs seem to pop up in only certain subsystems seems to indicate a really worst-case setup. Not only are they avoiding well tested libraries, but they aren't even using a single internal library consistently.

It seems oddly convenient that the problem will fix itself on Monday which would be the start of a new work week. If I had to guess they use that as the start of the week and schedule out the entire week from there and that processes just isn't handling crossing over to a new year properly. I understand not being able to push out a fix for this because realistically you don't want to rush something out and cause more problems and it's likely that most people wouldn't even end up applying the update before the problem fixed itself.

This is one of those times I wish Apple was more open. I'm very curious as to why Apple time systems seem to always screw up in the New Year and why DND will suddenly start working again January 7th. I recognize the above statements about how working with dates can be hard, but for Apple to be able to say a specific date to when it will magically start working again, they must know something, and with all the January-related problems, I question this being a "corner case".

I'd love to know exactly why too, mostly because some of the best learning is from mistakes. It's probably related to something specific to week long look-ahead/scheduling periods and year rollover, given the Jan 7th date. Which is probably how they know it will be working again on Jan 7th.

I've seen a similar issue crop up with 3 day look ahead on a calendar system that was hard coded to calculate days using 24 hours (as seconds) and didn't have daylight savings calculations built in. Once the daylight savings cross-over was out of the 3 day window it was fine. Fairly easily fixed without changing everything else in that case, but it never would have happened to begin with if it were fully using date/time library functions from the start. Also VERY easy to overlook.

Years are not exactly 365 days, hence the every fourth year mess. Days are not always 24 hours (and that varies by locale) even if you stick your head in the sand and ignore leap seconds (granted, in that case you'll get away with it for many things). If your clock in/out pay system just calculates the difference in time of day because you wrote it for normal day shifts and someone works overtime across a date interval it will mess up. Etc. It's all *fairly* basic when taken singularly and when you're already thinking ahead for worst cases, but you can spend a lot of time fixing issues that taking just a bit longer at the start to use proper libraries and models would have dealt with, and sometimes you'll be stuck with a choice between a big refactor, an ugly stopgap hack with other issues, or just telling people to work around it (like apple has basically done here).

Quote:

The fact that iPhone date bugs seem to pop up in only certain subsystems seems to indicate a really worst-case setup. Not only are they avoiding well tested libraries, but they aren't even using a single internal library consistently.

A really good point.

Personally I'm not cutting Apple as a whole any slack on this; I feel like they have the money to QA properly and to standardize their codebases, and they obviously know they have issues by now. I just find it interesting to speculate =)

You need to read more careful, both articles are about the same issue. The 2012 article reports that several users haven't updated to the than current iOS version and thus were caught by the bug again.

Only then will the planets and the stars be in the proper alignment for the Ritual of Sacrifice, where the yearly tribute of a virgin child can be fed into the maw of the Evil Incarnation of DOS3.0. Only thus has Apple been able to sustain itself through the years, and it hath used the power thus gained to become mighty. Yet if the Ritual be not done, e'en the mighty shall be struck low, and miss their appointments and calls.

I had noticed this morning that my iPhone was still in DND mode an hour after it should have stopped, but since I don't get that many phone calls and they end up going to VM most of the time anyway, I didn't worry too much about it - that said, I'm glad I saw this story as it explains what happened.

Same here. I figured it was some weird thing so I rebooted and it didn't help. Ended up manually turning it off. Thanks for the article letting us know.

First thought when it didn't work on Jan 1 was that they're using day of year (1-366) or mo/day as part of the comparison and 1>=365 or 0101 >= 1231 is never going to happen. You say 'Well of course that won't work, who would write that?', but I've seen it in code, and I've even seen code that only uses the day of month!

But now we find out it doesn't work only in the first week of January? That's a bizarre one. I'm guessing the week thing is because you can set DND by day of week. But you would expect that if it went to sleep 9pm Jan 1 that it would have no trouble waking up 6am Jan 2. It sounds like someone added some special code to handle end of year wraparound... and blew the code. We've certainly seen leap year code that actually makes things worse.

Either that or they're using week number (day/7) and one guy decided it was 0-52 and another guy has a check that assumes week numbers start with 1. Actually... it wouldn't surprise me then if week 0 were a naughty special case indicator.

I'd love to see the patch because I often come up with these possibilities where someone could have somewhat reasonably missed something or made a wrong assumption (I certainly have at times! but then where's the testing?) and then it turns out the code was brain-dead beyond anything I was imagining.