iOS 6: Do Not Disturb mode stays on after scheduled time
support.apple.com
support.apple.com
Calendar/time stuff is really, really hard. That's not an excuse for Apple in particular, just that the pitfalls are many and varied to the point where even smart people will screw it up.
I imagine one reason it doesn't seem so hard at first glance is because time and the calendar, in our lived experience, is relatively simple.
Actual implementations often look more like this: http://www.epoch-calendar.com/support/getting_iso_week.html
Implementing it as a one-liner would be an interesting code golf exercise.
It is not technically a bug but it real easy to get wrong. Perhaps they should have picked sometimg other than YYYY for week years.
Maybe there's code in there that checks day of week but it's hardcoded to run every day to make the UI simpler.
As others have noted, it'll break during leap seconds where a full second repeats and unix time "conveniently" forgets about it ever existing.
At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful and reliably consistent scales, so I don't see time getting much easier barring some revolutionary timekeeping system.
Yes, you still have to deal with timezones, but I'd much rather be given a UNIX timestamp for a UTC time and then adjust accordingly, rather than deal with all the other problems that come from communicating and converting between various other calendar formats and locales.
And this exchange should occur at the very last step, only when being displayed to the user. For almost any other purposes, there's no reason that two different applications should need to talk to each other using anything but UNIX timestamps. The potentially error-prone conversion should happen in the latest stage possible, because that's the part with the most knowledge of how any error should be corrected.
> At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful scales,
But we're talking about for programming purposes - to a computer, one 64-bit int is as good as any other.
It's a common mistake.
The first usecase is Birthdays. For most purposes people do not want to store the extract time and date of their birthday in the original time zone. Apple do this, much to my annoyance - it means people's birthdays change as you move around our planet, and that doesn't align with how they work in the real world. If I'm born in Utah on 1/1/1980 it does not mean I celebrate my birthday on 31/12 when I'm in Australia.
The second usecase is recurring meetings, particularly with global participants. The mind bending case is where you have DST in some or all of the TZs. The only remotely correct thing you can do is keep the meeting at the same wall-clock time in the TZ of the meeting owner (9am meeting stays at 9am). Most apps don't, and there is no perfect answer (consider a participant in a different TZ - the meeting changes to a possibly conflicting time).
Sometimes storing the absolute time/date is correct. Other times storing the original UTC offset, as well as the time in UTC is. But most of the time, yes, store it in UTC in whatever form you prefer.
Or between any two time formats, but Unix time still makes for the cleanest intermediary by far.
It's just that you can't do it with some formats, like UTC - Unix time or UTC - (only include the last 2 digits of the year like in Y2K)
TAI is even better, though. A steady stream of seconds after an epoch without leap seconds causing complications.
https://gist.github.com/4438567
(Yes, they gave TWO separate UNIX timestamps, neither of which corresponded to the actual time of interest).
http://appleinsider.com/articles/11/01/01/apple_admits_new_y...
Even the response to the problem is similar. Microsoft says, wait until the 2nd and the problem will resolve itself. Apple says, wait until the 7th and the problem will resolve itself.
[1] http://www.pcworld.com/article/156240/microsoft_zune_failure...
iPhones need timed mute like Shush! on Android [1] - press mute: it asks "how long?"
Going into the cinema? Mute for two hours. Meeting? An hour.
1. https://play.google.com/store/apps/details?id=com.publicobje...
It's simply staggering that this has apparently never occurred to anyone at Apple. The cheapest feature phone in a bubble package at Radio Shack supports silent ringtones -- or at least it did a few years ago -- but with the iPhone, the user has to record or purchase a track with several seconds of silence and create one manually.
I wrote an app that allows you to change the ringtone on someone else's phone (think xmas tunes, valentine songs etc etc). Anyway, one of my users had this issue where his wife is expecting a kid and he always has his phone on silent at work, so I've extended the app so that if he enables a web password, she can log in, turn his phone off silent and then ring him.
Before you say it, no it's not for iPhone but for Android. It's called TonePush Beta. All feedback gratefully received.
Okay maybe not.
So maybe it's using 11 PM yesterday as the trigger instead of 11 PM today.
http://arstechnica.com/gadgets/2012/11/december-conspicuousl...
programming can be a bit less hard if you learn to do it right.