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

TroyBoy30 said:

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

Click to expand...

Its a big issue to some. For example, I keep my phone on always. If there is an emergency, I want it to ring (favorites list), but lately I have been getting sms and calls in middle of night. So DND is a perfect balance. I am still amazed this is happening. I think it has to be a Unix bug.

throAU said:

Well, given that android's calendar missed out the entire month of december until it was fixed in an update, i'd say this bug is small fry.

Samsung/google would be standing in a nice big glass house throwing stones...

Click to expand...

Wrong.

This issue didn’t affect the calendar app at all. It was the date selector field in the People app which was missing the month. Google rolled out an OTA fix within a couple of days as well.

I also dont see the relevance of why you had to mention Samsung as well?!

While the bugs does suck for those of us that use it, I'm surprised that folks are all butt-hurt over the response Apple provided. I read in another thread that some developer found the bug and saw that it will fix itself next week and occur again the first few days of next year. This was posted before Apple made their official response.

Now let's look at Apple's IOS release cycle. I'm pretty sure 6.1 will not include a fix for something identified a few days ago unless they push the patch release date back. Further more, the bug will not occur again until next year so there is no need to rush out a patch right now. IOS 7 will be coming out this year and I'm sure this is when the issue will be addressed.

Waiting a few days should not kill anyone.

Hidesuru said:

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.

Click to expand...

Just because you don't define it as critical, does not mean others feel the same. I think DND is a critical feature to many. I for one can get calls all throughout the night and its nice not being woken up. If I turn my phone on vibrate or off, then those who can pass through the DND aren't heard. And with family members who are ill, I might miss something important.

annoying bug

This bug is really annoying. I am so used to not having my iPhone ring at times when I would be sleeping and I did not have to remember to set it or not set it. It just worked. Now I have to remember to turn it off during the day and turning it back on at night so I do not get disturbed.

Granted it is not a big deal but I am a person of habit and now until the fix on January 7th, I have to be conscious of the fact to turn the do not disturb on at night.

Bad Clock

If the bug will fix itself on the 7th, is it just bad coding. Does the phone have to talk to the mother ship just to use a feature that is basically a clock function?

Don't get me started on the crappy bluetooth. the issues are overwhelming.

I'm pretty confused that why this bug would happen.
As I see, this "Do Not Disturb" function seems to only care on the time only, without any date or year.
With the words of Apple, the problem will resolve itself on 7th.
Seems that the problem is linked with "weak of year", or something about date or year.
I have no idea how should this bug be "produced".

Just with my programming logic and experience.

Wolfpup said:

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.

Click to expand...

No. By that logic, if you rely on something, you don't use a feature that's designed to *disable* it.

If I need to hear my alarm clock, I don't use the volume dial to turn it down to the point where I can't hear it. Why? Because it defeats the purpose of having an alarm clock in the first place if you mute the thing.

If I need to be able to move around with my laptop, I don't use a desk lock which would prevent me from doing so.

If I need to get a phone call to know when I need to go to work, I don't use a feature which prevents the phone call from ringing through.

Understand yet? It's really not that hard.

- - - - -

Then again, you can configure DND so that phone calls from certain users will ring through *regardless* of whether the feature is active, so it's really a moot point trying to claim that DND turning off will prevent you from receiving your call. Unless you failed to properly configure it, that is.

----------

mw360 said:

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?

Click to expand...

Again, if you *need* to be able to hear something, don't use a feature which *mutes* it. It doesn't get any simpler than that.

Seriously, people. Use your heads!

tbrinkma said:

No. By that logic, if you rely on something, you don't use a feature that's designed to *disable* it.

If I need to hear my alarm clock, I don't use the volume dial to turn it down to the point where I can't hear it. Why? Because it defeats the purpose of having an alarm clock in the first place if you mute the thing.

If I need to be able to move around with my laptop, I don't use a desk lock which would prevent me from doing so.

If I need to get a phone call to know when I need to go to work, I don't use a feature which prevents the phone call from ringing through.

Understand yet? It's really not that hard.

- - - - -

Then again, you can configure DND so that phone calls from certain users will ring through *regardless* of whether the feature is active, so it's really a moot point trying to claim that DND turning off will prevent you from receiving your call. Unless you failed to properly configure it, that is.

----------



Again, if you *need* to be able to hear something, don't use a feature which *mutes* it. It doesn't get any simpler than that.

Seriously, people. Use your heads!

Click to expand...

You're absolutely missing the point. This is a feature that is, yes, designed to mute sounds. But it's ALSO designed to - get this - COME BACK ON. The designers didn't just stop at a switch to mute sounds or the damn *mute* switch would have sufficed. They designed a system to schedule on and off and yes, when you're paying goodness knows what for a top end phone you *should* be allowed to rely on it!

VulchR said:

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.

Click to expand...

The "problem" is that a feature isn't working. You find problems by shipping code that doesn't work and letting customers find it, or by testing and finding the problem yourself before shipping. The "error" which debugging is supposed to find is the code causing the "problem" which testing should have found.

coffeemadmanUK said:

You're absolutely missing the point. This is a feature that is, yes, designed to mute sounds. But it's ALSO designed to - get this - COME BACK ON. The designers didn't just stop at a switch to mute sounds or the damn *mute* switch would have sufficed. They designed a system to schedule on and off and yes, when you're paying goodness knows what for a top end phone you *should* be allowed to rely on it!

Click to expand...

I *can* rely on mine. I don't use features which make it less reliable for me.

Again, if you *really* need to get a phone call or alert, configure DND so that it *doesn't* mute that phone call or alert. The *only* part of the DND feature that isn't working is the automatic deactivation.

If you don't configure it properly, don't blame someone else when you miss a call or alert because the feature was on.

Would it be Apple's fault if the call came a few minutes *early*, so DND was still active? It's the same end result. A feature, used to stop you from hearing alerts, stops you from hearing an important alert. If you don't want it doing that, either don't use it or make sure it's configured so that important alert won't be blocked.

gnasher729 said:

The "problem" is that a feature isn't working. You find problems by shipping code that doesn't work and letting customers find it, or by testing and finding the problem yourself before shipping. The "error" which debugging is supposed to find is the code causing the "problem" which testing should have found.

Click to expand...

I've been programming for over 30 years. To me debugging means actively searching for errors by testing software extensively, particularly at boundaries like date changes. Perhaps the more modern practice is to split debugging from testing, but it doesn't sound like that approach is very successful. In any case, whether you want to call it 'testing' or 'debugging' makes no matter - somebody at Apple was well asleep at the switch.

Hi guys,

I have the issue described. Switching the DND function on and off does not resolve the problem.


I had read that it should 'fix itself' come Monday. Well, it's Monday for me now...and it's still broken.


Is there something I need to do to prompt the magic fix?


Cheers in advance,


Ben

I am sure it will get sorted but in the meantime just switch it on & off manually people do like to moan

Mr-Kerrse said:

I am sure it will get sorted but in the meantime just switch it on & off manually people do like to moan

Click to expand...

That's not really point is it. Thank you for your help...naaaaaat!

Mine turned off at the normal time today, 9AM.

I'm not going through 12 pages of moaning and over reaction to see if this has been posted already:

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.

Read more at http://www.cultofmac.com/208217/why...properly-until-january-7/#AT9X4rwpMxs2yBEj.99

ikramerica said:

Sell everything you own and live in a Yurt, and donate everything you have and make to causes to help those starving people.

Otherwise, you are just a hypocrite. Just like those who cry 'first world problem' anytime something happens they don't consider a big deal because it didn't actually impact them.

For many, this happened on the first business day of the year (January 2, not Jan 1) after a very spotty week of days off, holidays, etc. That means that they may have missed a call about a deal, a sale, a job, etc. Would you think it was meaningless if you lost out on buying a house for your family because you didn't get a call regarding counter offers and deadlines? Or lost a sale that meant a big account? Or missed an emergency call when you are an OBGYN, delaying you even an hour? All because you DIDN'T KNOW THE FEATURE WAS BROKEN? Or, despite Apple knowing it would impact a huge number of people on January 2 but not January 1, not being warned about it?

I'm already fed up with Apple with the lack of reliability of the iPhone 5. WiFi is horrible, LTE to 4G switchover is broken, purple haze in videos is unavoidable in many cases unless you stand perfectly still. And I'm not to happy with my mini server which never seems to remain up 100%, forcing restarts when it "loses contact" with hard drives over FW800 or can't maintain a "share screen" connection to administer it (under snow leopard or now mountain lion), which kind of makes it pointless as a server. And none of this is being addressed by Apple. They just let it slide.

And this response by them just feels like more of the same.

Signed: 22 year Apple customer who's bought his last Apple product...

Click to expand...

Exhibit A.

Ugh, glad someone else called out that "first world problem" BS. Just an excuse to allow anything and everything, cut any dissent, any thought, and debate about anything. Dangerous BS.

Regarding this bug, is it working now? I haven't paid much attention since the 7th, and I know it wasn't working right then as I was hearing my iPad dinging at me from the other room when it shouldn't have been.