Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Says 'Do Not Disturb' Bug to Resolve Itself on Monday, January 7th
- Thread starter MacRumors
- Start date
- Sort by reaction score
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.
You don't even have to turn it *on*. Leave it scheduled, but turn it off when it's supposed to turn off.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
----------
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.
----------
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.
Every year it conveniently resolves itself, only to come back next January 1st. So it never gets fixed.
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.
In the time it would take to fix the bug it will have fixed itself!
EDIT: beaten to it I see.
Last edited:
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.
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.
Well that's impressive since iOS did not have DND last January..... Lol.
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.
Read the thread:
Post #235:
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.