It seems every time there's some change in the calendar in some way, iOS throws a cog somewhere. This time, the change of year has thrown iOS 6's 'Do Not Disturb' function into a bit of a lather

Basically put, the scheduling part of DND is currently not shutting the function down in the morning, which means phones are effectively staying in 'silent' mode unless specific conditions are met.

As the article states, this will apparently fix itself on the 7th (not sure how that works but anyway) but until then anyone with DND on needs to remember to switch it off every morning.

It's not a fault. it's a feature as marklar77 would argue, Apple in their infinite wisdom wishes everyone more time away from the bustle of life

shudders

Actually I do rather wish that, rather than 'do not disturb,' they'd called it 'Just [lifted] off!'

People are speculating that this is due to the date format used.

When you use YY or YYYY in the date format you get the year of the current day.

i.e. YYYY on 6th Jan (yesterday) will show 2013.

But when you use yy or yyyy in the date format you get the year of the current week.

i.e. yyyy on 6th Jan (yesterday) will show 2012 (i.e. the year from Monday 31st Dec as Monday is the start of the week).

People say the wrong format was being used and so throwing off the DND feature.

This also explains why it fixes itself today because from now on the year of the week will be the same as the year of the day.

^
I really wish I understood that, but I don't!

Basically put, the prof is saying if you code telling the app to use a particular form of request to the 'tell me what the date is' function, it uses 'the year on the first day of the week' to count for the whole week. So given New Year's day was midweek, the app was late in figuring out it was 2013 not 2012.

The thing is, I don't see why this would be the issue. The DND app doesn't care what the year, date or even the day of the week is, it only goes on times. My DND is set to start at 23:00 and switch off at 07:00. Every day. For ever. Unless the fault in the date function causes causes the data it sends back to be utterly spurious, I don't see why the DND code should even bother to check what the date is. If Time >END AND Time <START, DND is off, else it's on. No need to worry what the date is at all.

You say "time" though.

There is no such thing as a time. The only thing you have is a dateTime. This is stored purely as a number. I think it is the number of milliseconds since jan 01 2001.

In order to get the time you need to query the entire thing.

I'm aware of how the Unix dates work. However that doesn't explain the error. The phone knows exactly what the correct time is, to an almost mind-boggling degree of accuracy. That must be transferred up through the kernel to the OS (possibly being converted to a Unix datetime format along the way) and thence to NSDate constructor requests correctly, or the whole phone would break - the date say on the calendar app didn't say 2012, so we know NSDate objects must have been being instantiated with the correct values. Once you have an NSDate object, you can get the hour and minute values without reference to the year at all. You've long since left the world of Unix datetimes behind.

The explanation of how the specific wrong method call might cause that bug and why it would fix itself are valid, but there's no reason for the DND code to actually ever make that method call. They'd have to do a mass of extra work to make that value relevant to the code they were writing, when the simple route that wouldn't have broken was there in the documentation that they'd have to reference anyway to do it the 'wrong' way.