Ask Ars: Why will Apple’s Do Not Disturb bug fix itself next week?

Bug pops up as Apple advertises DND feature in new ads.

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."

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's Do Not Disturb ad, "Dream"

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!'"

Promoted Comments

Regarding the "why is Apple using dates in the first place" question, I bet the answer is something as simple as the code that is created for DND to be automatically switched on/off, is far more generic, and probably allows you to set a more fine grained schedule (e.g., it might have capabilities to switch on/off on weekends, or maybe even calendar holidays). Apple might have chosen to only expose the limited UI we see right now, but since it is running off the same code, we see these issues.

63 Reader Comments

I once left a detailed suggestion to Apple via their bug reporting system to the effect that, next April Fools' Day, Apple should do some kind of epic troll of all iOS and iPod users, essentially showing a dead battery icon the first time you go to use their device on April 1, then show a brief April Fool's message, then operate normally. I got a reply from some manager thanking me for the suggestion, saying how much they appreciate ideas like this. It never got implemented though, probably from someone getting cold feet over a glitch crashing the stock price if something wernt wrong.

[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.]

Possibly Ars needs to employ the same disciplinary procedures.

Edit: That said, I expect the problem is actually that the first week of 2013 started in 2012.

This reminds me of the 2008 Zune bug, when all Zunes stopped working on Dec. 31 because 2008 was a leap year and Zunes didn't "understand" how there could be a 366th day in a year.

The biggest problem with dates is that days and years don't align. A year lasts 365.2496 days. You can't make time units that "make sense" (like you can for distances in the metric system) because of that.

Thanks Jacqui. Looks like it's as we were speculating in the other thread, except for the unsolved whyyyyyy. I'm guessing that at some point they expected to do DND by day of week so picked the week format, but it would be far less error prone to just ask the OS to tell you the current day of the week from a less bizarre date format.

QFT. Why does this happen to a major tech company almost every year? How can you not use the calendar library that comes with pretty much every major programming language?

We just told you. Because dates are hard, no matter how good libraries are. Time units don't align.

If I told you the first foot of a yard starts at the third inch, but only once every four mile you measure unless you're measuring your 400th mile, that yards are successively 4-2-4-3-4-3-3-4-3-4-3-4 feet, would you say measuring long distances is something that everyone should be able to get right the first time?

I'm not saying they shouldn't get it right, I'm just not surprised it happens.

We're not even talking about historical date oddities, like when we skipped 10 days between Oct. 4 1582 and Oct. 15 1582.

This reminds me of the 2008 Zune bug, when all Zunes stopped working on Dec. 31 because 2008 was a leap year and Zunes didn't "understand" how there could be a 366th day in a year.

The biggest problem with dates is that days and years don't align. A year lasts 365.2496 days. You can't make time units that "make sense" (like you can for distances in the metric system) because of that.

So, really, what we should do is spend billions on devising a way to change the Earth's orbit around the sun in order to make it a better number! 400 days/year would be so much more convenient!

Regarding the "why is Apple using dates in the first place" question, I bet the answer is something as simple as the code that is created for DND to be automatically switched on/off, is far more generic, and probably allows you to set a more fine grained schedule (e.g., it might have capabilities to switch on/off on weekends, or maybe even calendar holidays). Apple might have chosen to only expose the limited UI we see right now, but since it is running off the same code, we see these issues.

I'm still having problems understanding the issue, probably (because others have stated) I'm not the greatest coder.

DND occurs between say 11pm and 8am. The timezone, date, month and year are all inconsequential. If the time is between 08:00 and 22:59 then DND should be off, else it should be on. I can't see any value in knowing whether or it's Monday 1st January 2013 or Friday 15th July 1995.

Whenever the clock time changes (eg. timezone change, daylight saving change, user change) just re-run the check above again. If you move from GMT to PST and the time changes to 2am, then the phone should switch to DND - it is, after all, now 2am.

Finally you just need a periodic check to ensure that the time hasn't ticked over to outside of the DND window. There must be 101 things that are checked every second, does adding a further check in that loop really impact battery life?

What am I missing?

EDIT: Oops, that final check could probably happen only when the seconds value = 0. No point in checking it every single second when at the point the minute changes will do.

Why would it need to deal with dates? Well, wouldn't it need to tell some event handler to turn on/off DND in the future?

I would expect it would have to tell some subsystem to do something on x/x/x/ at x:xx time. It's not like the DND app itself would be actively waiting for the time to change. Sort of like setting up a CRON task.

I'm still having problems understanding the issue, probably (because others have stated) I'm not the greatest coder.

DND occurs between say 11pm and 8am. The timezone, date, month and year are all inconsequential. If the time is between 08:00 and 22:59 then DND should be off, else it should be on. I can't see any value in knowing whether or it's Monday 1st January 2013 or Friday 15th July 1995.

Whenever the clock time changes (eg. timezone change, daylight saving change, user change) just re-run the check above again. If you move from GMT to PST and the time changes to 2am, then the phone should switch to DND - it is, after all, now 2am.

Finally you just need a periodic check to ensure that the time hasn't ticked over to outside of the DND window. There must be 101 things that are checked every second, does adding a further check in that loop really impact battery life?

What am I missing?

See the post immediately above yours. I suspect arcadium is right and Apple was initially planning on allowing a more fine-grained approach involving days of the week or something to that effect.

2013 started on Monday December 31st according to the YYYY ISO standard.

Somewhat interestingly, iCal (desktop) gets the first week of the year correctly.

Aside: this is where Apple ticks me off, the inconsistency between desktop and mobile. For example: on desktop calendar, can add >2 alarms, but only two go to mobile. Can set repeat events on desktop Reminders, no repeat on mobile. Sure, stuff syncs across devices, and works if wanting to get a place-holder event/reminder in place when away from desktop, just now have to remember (or add a reminder) to go to desktop and clean up things. And in the case of iCal, I now have to export my events to Google Calendar and setup the other alarms I want as a text messages (for example). Again, more work.

ADD: I don't ever remember my Palm Pilots having the date/time issues that Apple does. The one thing I do miss from Palm was their calendar and to-do apps: feature rich and worked, IMO.

This reminds me of the 2008 Zune bug, when all Zunes stopped working on Dec. 31 because 2008 was a leap year and Zunes didn't "understand" how there could be a 366th day in a year.

The biggest problem with dates is that days and years don't align. A year lasts 365.2496 days. You can't make time units that "make sense" (like you can for distances in the metric system) because of that.

So, really, what we should do is spend billions on devising a way to change the Earth's orbit around the sun in order to make it a better number! 400 days/year would be so much more convenient!

This reminds me of the 2008 Zune bug, when all Zunes stopped working on Dec. 31 because 2008 was a leap year and Zunes didn't "understand" how there could be a 366th day in a year.

The biggest problem with dates is that days and years don't align. A year lasts 365.2496 days. You can't make time units that "make sense" (like you can for distances in the metric system) because of that.

So, really, what we should do is spend billions on devising a way to change the Earth's orbit around the sun in order to make it a better number! 400 days/year would be so much more convenient!

I've had a think about this, having both fixed and made a few date/time issues in a past life, and my guess is that the code assembles date/times from the DND values, for when to switch on and when to switch off (or possibly, to compare against the current time)

If it were incorrectly applying a date format with strftime() or similar (as posited here, one that does different things with yyyy and YYYY) then it could result in simply generating incorrect start and/or end date/times.

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.

The first Thursday in January is today, January 3, 2013. Therefore using the ISO format, the first week of 2013 started December 31, 2012, not January 7, 2013.

Perhaps Apple implemented the ISO standard incorrectly and ignored the Thursday part - meaning in Apple's view, the first week of the year is the week that has the first Monday. IF that was the case, I would have expected it to manifest itself in other places that also rely on YYYY so there's really no telling at this point.

agonist wrote:Dates are not difficult to deal with if you're a good programmer. Makes me wonder about some of the people Apple has writing code for them.

Thanks for letting us know that you have no experience dealing with time objects.

Another thing that can be a huge pain with time is the different time zones, and which countries/states/cities observe and don't observe daylight savings time.

Nothing about how time is measured lines up. Which is why I propose we move to a stardate time system which has nothing to do with how many times earth spins, or how long it takes to move around the sun.

For example, 1/3/2013 will yield 2013 whether you're using YYYY or yyyy. 12/31/2012 will yield 2012 if using yyyy and 2013 if using YYYY since the Thursday of the week its on has a yyyy of 2013.

The article (and the source it links to) both originally missed the fact that 1/1/2013 and onward all yield 2013 as the year regardless of YYYY vs yyyy. The source article has since corrected its mistake.

2013 started on Monday December 31st according to the YYYY ISO standard.

Not entirely correct. ISO and Gregorian always have the same start of any year: directly after 31 December 23:59.

However, Gregorian doesn't have week numbers. Considering week numbers are vital for businesses ISO 8601 has set a standard for week numbers. That means that if I tell my suppliers to plan X for week 21 while I bill my client for services in week 21 and our finance people recognise X revenue for week 21 we are all talking about the same week.

ISO 8601 defines week 1 as "the week with the year's first Thursday in it "

That doesn't mean 2013 started earlier, it only means that this year week 1 included the last day of 2012.

...Finally you just need a periodic check to ensure that the time hasn't ticked over to outside of the DND window. There must be 101 things that are checked every second, does adding a further check in that loop really impact battery life?

What am I missing?

EDIT: Oops, that final check could probably happen only when the seconds value = 0. No point in checking it every single second when at the point the minute changes will do.

Even better.. just check it every time an event which would cause an alert occurs.. like receiving a phone call or text message.

"The ISO week numbering system uses the YYYY format for the year instead of the Gregorian calendar's yyyy."

I'm sure that sentence means something, but I can't figure out from the article what it would be.

YYYY and yyyy are codes for date formats in some universal data standard.

Each component of a date (day, month, week, year) can be converted to a number in multiple ways (e.g. what day does the week start on, is the first day/month/year 0 or 1). Programmers use this standard so they don't have to explain how a date is calculated every time they write a chunk of code (most full featured programs are written by teams of developers/programmers so common understandings are critical).

Look at the help file for any tool that lets you record dates in various formats, and you'll get a long of letter codes where upper and lowercase can mean completely different things.

Precision time keeping gets even weirder. For those who say "just define it via an atomic clock," remember that atomic clocks at sea level, Denver, and low earth orbit all run at different speeds (time really is slower in a gravitational potential well). And for those who say "fine just define it as x fractional rotations of the earth," not only does the earth's rotation slow down over long periods of time (the xkcd link) but it speeds up and slows down with the *weather*. A big storm system will temporarily steal angular momentum from the crust, slowing down then speeding up your apparent rotation around the planet. So precision time observations must be corrected after the fact for the observed rotation of the earth, e.g. you have to wait a week or so to accurately know what the rotational time was!

Dates are not difficult to deal with if you're a good programmer. Makes me wonder about some of the people Apple has writing code for them.

It's the programmers who think that dates are not difficult to deal with that make these mistakes.

Dates and times are notoriously difficult. That is why, just like for encryption, it is recommended not to write your own date/time code but use existing time-tested libraries where possible.

And even those do not always work reliably. I had a call center located in asia that used the built in date routines in Windows NT to schedule customer calls. We discovered that Microsoft had failed to test their algorithms in time zones with positive offsets from GMT, with the result that calls to customer's homes occurred one hour early, generally getting the now former customer out of bed just long enough to terminate the business relationship.