Apple Says 'Do Not Disturb' Bug to Resolve Itself on Monday, January 7th

[Bubba Satori]

Originally Posted by TroyBoy30

omg the world is ending. such a small issue. i didnt even know dnd existed. if i dont want to be disturbed i cut my phone off

That's the spirit.

[Southern Dad]

I actually love this feature and can't wait for it to be fixed. Keeps the politicians, telemarketers and such from calling during certain time while still allowing important calls from people that I want to talk to.

[The Bogeyman]

Um..... Mine worked flawlessly. No sign of a bug for me.

[nazaar]

This is just bad PR and bad programming = a bad Apple

Makes me feel that all this talk of Apple turning sour will be true.

[tbrinkma]

Originally Posted by chazwatson

Are you really too lazy to turn it on and off?

You don't even have to turn it *on*. Leave it scheduled, but turn it off when it's supposed to turn off.

[gnasher729]

Originally Posted by VulchR

Sloppy on Apple's part - doesn't anybody there do any debugging anymore? Heads should roll. Oh wait....

It's not a matter of testing (testing, not debugging, is what you meant. Debugging happens when you know there is a bug). The feature itself is not in any way related to dates. You can tell your iPad "turn 'do not disturb' on every night from 10pm to 7am". Every single day. There is nothing in this that has anything to do with actual days. The only explanation why this would go wrong is some overly complicated code by someone who doesn't know how to do this, and then some bug in that overly complicated code (but in my experience, code that does things in an overly complicated way indicates that someone didn't understand the actual problem, and that kind of code tends to be buggy). If I or any of my colleagues had written the code, the person reviewing the code would have said "why are you doing it in this complicated way?" and it would have been changed.

Now if you set "do not disturb" to 2:30am to 5am then there is a problem that needs testing. (I hope you can figure out what the problem is that happens once a year, and the other problem that also happens once a year, and I would hope someone tested that case).

[Frign]

Originally Posted by sesnir

As a programmer, I'd be interested to learn why it will resolve itself on January 7th. Is it because it's the first Monday of the year? That would line up with last year's bug fixing itself on January 2nd.

This is it actually. The NSDate(Components) can be faultily implemented and not take respect of the "nil-week" of each year.
I once ran into those problems and solved it using UNIX-time, which is much more reliable but far less flexible.
I am sure that Apple can easily address this issue, especially because I am more into GNU/Linux and not as skilled as their engineers in this proprietary API.

[tbrinkma]

Originally Posted by Michasss8

It is not... And this is not the most important thing.

Look from the other side.

What if you weren't woke up to job because such a mistake of Apple? The problem is not about flicking it.

1) User-set alarms still sound while DND is activated, so set an alarm to wake you up.
2) If you're relying on a phone call to wake you up for work, maybe you shouldn't turn on a feature which could make you miss it if the person calls a bit early.

[coffeemadmanUK]

Whilst I didn't have this issue, I did find that the "more than one call in three minutes" rule was ignored, leading to a very unhappy partner left outside the house in the early hours!

Is this related or a different issue?

----------

Originally Posted by tbrinkma

1) User-set alarms still sound while DND is activated, so set an alarm to wake you up.
2) If you're relying on a phone call to wake you up for work, maybe you shouldn't turn on a feature which could make you miss it if the person calls a bit early.

To some extent we all rely on technology to get us up and about every day.

If you had an alarm clock, put fresh batteries in it and they went dead overnight and you missed your alarm, I doubt you would be happy if the response you got from the battery company was "well you shouldn't RELY on this" etc.

[jessica.]

How do things just resolve itself? My DND does t seem to want to turn on as scheduled.

[tbrinkma]

Originally Posted by coffeemadmanUK

Whilst I didn't have this issue, I did find that the "more than one call in three minutes" rule was ignored, leading to a very unhappy partner left outside the house in the early hours!

Is this related or a different issue?

----------



To some extent we all rely on technology to get us up and about every day.

If you had an alarm clock, put fresh batteries in it and they went dead overnight and you missed your alarm, I doubt you would be happy if the response you got from the battery company was "well you shouldn't RELY on this" etc.

You're talking about a bug where a feature designed to *prevent* your phone from making unwanted noises fails to turn off. If you absolutely *rely* on being able to hear the noises affected by that feature in order to make it to your job, you shouldn't have turned that feature on in the first place.

Or just add the expected caller(s) to the list of people you allow calls from during the scheduled DND period, and remember to turn it off when it's supposed to be off until the 7th.

[Wolfpup]

Originally Posted by tbrinkma

You're talking about a bug where a feature designed to *prevent* your phone from making unwanted noises fails to turn off. If you absolutely *rely* on being able to hear the noises affected by that feature in order to make it to your job, you shouldn't have turned that feature on in the first place.

As the post you're responding to points out-that's absurd. By that logic you can't rely on ANYTHING whatsoever to actually do its job.

[Rodimus Prime]

Originally Posted by Frign

This is it actually. The NSDate(Components) can be faultily implemented and not take respect of the "nil-week" of each year.
I once ran into those problems and solved it using UNIX-time, which is much more reliable but far less flexible.
I am sure that Apple can easily address this issue, especially because I am more into GNU/Linux and not as skilled as their engineers in this proprietary API.

There is a risk using Unix time for this like this. Unix time does not take into account Timezones so now you have to add in code to address that and do proper adjustments.

Originally Posted by TroyBoy30

omg the world is ending. such a small issue. i didnt even know dnd existed. if i dont want to be disturbed i cut my phone off

It not so much that but more the fact that Apple tends to give responses like this quite often and has been having massive problems with alarms and anything schedule all the time. This is not the first time the New Year issue hit them. They have DST issues quite often and multiple times in a row. It sad that Apple is still having these massive embarrassing issues. Where I work we had one of these issue hit us this year and I can promise you that it will be the first and last time it hits us because it got added into require test casing before a release to make damn sure it does not happen again. We also shoved out a patch the day we found out about it with an extermely getto rigged patch just to buy us time to find and fix it correctly which yes we did do.

[Hidesuru]

Originally Posted by unplugme71

So what happens next year?

And what about other issues? Should we turn our phone off for several days?

Unacceptable Apple!

I didn't even read past the first page because I couldn't take the collective volume of all the whines. Dear lord it's not a critical feature of the phone. Useful, yes, but its not stopping you from getting everything else out of it you want.

Furthermore, there are several reasons the delay may be perfectly valid. For one, it could be date related and they know they will fix it in an upcoming patch, so the best solution is to wait it out. Would you prefer they push out a patch real fast that has a chance of causing other bugs? No matter how good they are, if you have insufficient testing this is a real possibility. I remember my moto droid several years back, and the bug that caused the camera autofocus to not work every other week or something like that till they fixed it. These things happen.

Also, it may not be date related, but going to be fixed in the next patch, which is scheduled for the 7th. Same reasons apply here re: testing so I wont belabor the point.

Everyone just settle down, grab your juice boxes and pacifiers, and wait for it to get fixed. If Apple "didn't care" they wouldn't have looked into it and either fixed it or determined it will correct itself on the 7th.

Dear lord.

[mw360]

Originally Posted by tbrinkma

You're talking about a bug where a feature designed to *prevent* your phone from making unwanted noises fails to turn off. If you absolutely *rely* on being able to hear the noises affected by that feature in order to make it to your job, you shouldn't have turned that feature on in the first place.

Why can't we rely on this this feature? Is it inevitably crap? What bits of our iPhone CAN we rely on? What bits of OSX can we rely on?

[Hidesuru]

Originally Posted by Rodimus Prime

It not so much that but more the fact that Apple tends to give responses like this quite often and has been having massive problems with alarms and anything schedule all the time. This is not the first time the New Year issue hit them. They have DST issues quite often and multiple times in a row. It sad that Apple is still having these massive embarrassing issues. Where I work we had one of these issue hit us this year and I can promise you that it will be the first and last time it hits us because it got added into require test casing before a release to make damn sure it does not happen again. We also shoved out a patch the day we found out about it with an extermely getto rigged patch just to buy us time to find and fix it correctly which yes we did do.

Sorry, "massive embarrassing issues"? I must have missed something, I was only aware of one minor bug! No, I am not an Apple fanboy (I hate them, but still use the phone) but this one is ridiculous. I'm (presumably also though you didnt say this) an embedded software engineer, so I know something about testing and patches as well. I'm guessing "where you work" (and I don't fault you for not listing it, I wouldn't either) you have a -few- less customers than Apple does.

Also there is a high probability that your product is less complex with regards to configuration than the iPhone (essentially infinite when you add in the different combinations of apps the phone can have). This makes a huge difference in how smart it is to push out "an extermely getto rigged patch". I think Apple would have to be full of brainless idiots to do something like that with all the possibility of causing further harm and the blowback that causes. Not to mention it creates revision control headaches as they are not doubt working on newer code (6.1 beta) and this would be an earlier branch. Im sure they can handle something like that, but just sayin.

----------

Originally Posted by tbrinkma

You don't even have to turn it *on*. Leave it scheduled, but turn it off when it's supposed to turn off.

Not true, mine failed to turn on last night when it was scheduled to do so.

Granted from my other posts you will see I agree this is a minor, temporary annoyance, but wanted to let you know.

----------

Originally Posted by mw360

Why can't we rely on this this feature? Is it inevitably crap? What bits of our iPhone CAN we rely on? What bits of OSX can we rely on?

I don't think that was his point. He was saying if you rely on "The noises" that are blocked by DND (not the feature), you shouldn't use DND, as it may prevent what you need to hear from occurring. I assume this is in reference to his earlier comment that if you get a phone call to wake you up for work every day they could call early and you wouldn't get up for work even if the feature acted as advertised. I assume this partly because he also pointed out that user alarms still go off with DND on.

Granted I am assuming what someone else meant, so grain of salt and all that.

[cppguy]

Every year it conveniently resolves itself, only to come back next January 1st. So it never gets fixed.

[bobr1952]

Originally Posted by KPOM

That's not what they said. You can manually turn it on or off. My guess is that by the time they got a patch out, it would already be 1/7/13. I noticed the issue on mine yesterday, but after manually turning it off yesterday, it seems to have resumed normal functions (meaning it turns on and off as normally). The risk in rushing out a patch is that they inadvertently screw up something else. This isn't affecting everyone who uses DND.

That was my feeling on this too--and one would also think that they will fix it so it doesn't happen again next year but I personally don't think this small issue is worth rolling out an emergency patch when it will resolve itself in a few days. Seems like a pretty insignificant little bug to me.

[powers74]

Originally Posted by Pagemakers

Christ, can't they just fix the dam BUG in a mini update?

In the time it would take to fix the bug it will have fixed itself!

EDIT: beaten to it I see.

[spazzcat]

Originally Posted by AidenShaw

Didn't Apple already fire the slimy dude responsible for IOS?

That has nothing to do with the engineer(s) that do their date programming.

[Idefix]

It's really quite simple:

Apple itself has the "Do Not Disturb" turned on until January 7. Don't disturb them!

This is a feature, not a bug!

[VulchR]

Originally Posted by gnasher729

It's not a matter of testing (testing, not debugging, is what you meant. ....

debug |dēˈbəg|

verb ( debugs, debugging , debugged ) [ with obj. ]
identify and remove errors from (computer hardware or software)

noun
the process of identifying and removing errors from computer hardware or software.

Alternatively: verb or noun - that which Apple doesn't do, apparently.

[shandyman]

Originally Posted by powers74

In the time it would take to fix the bug it will have fixed itself!

EDIT: beaten to it I see.

Plus it probably will be included in an update anyway, either in a 6.0.x or 6.1

It's surprising how many people on here think that apple could rush out a fix before the weekend. Well they could but in doing so probably sacrifice some QA time and risk the fix breaking something else. Simply apple cannot win so rather than rush out a sloppy fix, they'll fix it right knowing it will resolve itself anyway and ensuring it won't happen next year.

Originally Posted by cppguy

Every year it conveniently resolves itself, only to come back next January 1st. So it never gets fixed.

Well that's impressive since iOS did not have DND last January..... Lol.

[Archer1440]

Missed a call from my company president this morning because of this. First time in years I've been directly affected by an Apple bug. Ironically I first learned about this issue here. What's puzzling is, the feature worked fine yesterday- took the phone out of DND right on schedule at 630 AM. So, I figured I was unaffected. But not today.

[bedifferent]

Originally Posted by dontpannic

Oh really? So how was DND on iOS 5? Was it a hidden feature or did you jailbreak to get it?

The only bug remotely similar to this was alarms needing to be reset after the switch from daylight savings time, not 'this exact bug'!


It's a bloody silent switch, a minor bug that will resolve itself in 4 days time. It's not a fundamental flaw, it's not a fundamental feature. Yes it's slightly irritating, but is it really so hard to open the settings app to flick it on and off manually for a few days?

Originally Posted by tbrinkma

The second year in a row where "this exact" bug occurred? Wasn't DND new with iOS 6, released (much) less than a year ago? Or are you confusing "this exact" bug with a similar (but different) one which occurred in Jan 2011? You do also realize that user-set alarms still function normally even with DND activated, right? DND just stops things like email alerts and the like from making noise.

Read the thread:

Post #235:

Originally Posted by bedifferent

Of last year, this is the second time in a row a crucial time based feature over New Years has failed on iOS (last year alarms became mysteriously disengaged/hindered after the new year).

The second year in a row in which programmers failed to catch another New Year's bug involving time based feature(s). If you read the thread before commenting, you would have also learned the "bugs" were easily found by simply reviewing the code. It's sloppy and simply brazen for Apple to dismiss this by telling people to "wait it out" as they did last year. QA should have taken last years dilemma into account and been more thorough in their reviews. Period.