Why Apple’s Do Not Disturb Feature Won’t Work Properly Until January 7

Do Not Disturb on. Even when you don't want it to be.

Do Not Disturb on. Even when you don’t want it to be.

As I’m sure you’re already aware by now, the Do Not Disturb feature Apple debuted with iOS 6 stopped working as it should on Tuesday as the world turned over into 2013. While it has no problem activating itself when it’s told to, it doesn’t understand when it should shut off, meaning users must do it manually or they’ll miss their notifications.

Apple’s promised that the feature will automatically fix itself on January 7, but why did it stop working in the first place? And why will it suddenly start working as it should on Monday? Well, it seems Apple has trouble when it comes to date and time handling.

Following a bit of testing, Richard Gaywood over at TUAW discovered that the Do Not Disturb feature in iOS 6 doesn’t roll over into a new year until the first Monday of that year. So, for example, if the first day of 2013 was a Monday, it wouldn’t be an issue. But because it landed on a Tuesday, we must wait until the following Monday for DND to work out exactly where it is.

The reason behind this appears to be a simple coding error from Apple. In short, instead of specifying the year as “yyyy,” it is specified within the code as “YYYY.” The difference is simply one’s written in lower case letters while the other isn’t, which may seem insignificant to some of you — it certainly does to me; but apparently that variation makes a whole lot of difference because it uses the ISO week number system.

The ISO week numbering system uses the YYYY format for the year instead of the Gregorian calendar we’re all used to that uses yyyy. What ISO system does is it looks at which week of the year it is, and then uses a date digit with 1 starting on Monday. For example, Tuesday of the 50th week of 2012 would have been 2012-W50-2 in ISO week format.

Gaywood explains why using that method is a problem:

The ISO standard 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!

As our friends at Ars Technica have pointed out, the perplexing thing about the DND bug is that Apple’s own documentation warns developers on how to avoid this common error.

So between January 1 and January 6, DND still thinks it’s 2012. Well, part of it does; strangely the bit that handles activation of the feature works as it should, while the bit managing deactivation doesn’t. On the first Monday of the year, however, it’ll tick over into 2013 — that’s why DND will function as it should from January 7.

What’s interesting is that this isn’t the first time Apple has had issues with dates in iOS. It had daylight savings issues in 2010, 2011, and again in 2012, while a recent issue with the Calendar app causes it to crash if you may an all-day appointment on April 1, 2013.

“It wouldn’t be unfair to describe Apple’s reputation for date and time handling as a ‘rather poor,’” Gaywood concludes.

Don’t expect a patch of software update on January 7 to fix DND, then — just expect it to work as it should.

Related
  • technochick

    So Apple follows a standard and gets dissed for it. Good to know.

  • Shahin

    But why does the year have anything to do with DND? DND settings are based on time of day, so why should it matter what day, month, year it is?

About the author

Killian BellKillian Bell is a staff writer based in the U.K. He has an interest in all things tech and also covers Android over at CultofAndroid.com. You can follow him on Twitter via @killianbell.

(sorry, you need Javascript to see this e-mail address)| Read more posts by .

Posted in News | Tagged: , , , , , , |