Slashdot Mirror
iPhone Alarm Bug Leads To Mass European Sleep-in
nk497 writes "A flaw in the alarm clock in iPhone 4s gave Europeans a bit of a lie-in this morning. While the Apple handsets automatically adjusted to daylight savings time, a bug in the alarm system meant many were woken up an hour later than they should have been, after clocks rolled back over the weekend. Annoyingly, Australia was hit by a similar problem last month, but Apple failed to fix the problem or even warn users. American Apple fans, consider yourselves warned. The iOS4 bug can apparently be avoided by using one-off alarms, rather than pre-set regular wake-up calls."
my girlfriends 3gs (running iOS 4.x) had the same bug this morning.
Fortunately, my $99 android phone woke us up at the right time
People, what a bunch of bastards
What a bunch of whiners. Apple tries to do something nice for you, give you a little more time in the morning, and this is how you thank them?
Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
I would have gotten a first post if it wouldn't be for those meddling kids at Apple!
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Yes, its a ridiculous story.
Get a proper alarm clock for redundancy if you're in a job so sensitive that oversleeping once will get you fired, even with no history of tardiness.
If you're really paranoid, make it a wind-up clock so you don't have to worry about losing power.
The real bug is that we change the time at all, considering all the problems it brings.
With all new fancy (and not so fancy gadgets), you can NEVER be sure has the damn thing changed the time correctly or not. So you wind up watching weather forecast on TV, only to check the clock in the corner.
Note to engineers everywhere: if your gadget DO change the time, please use some kind of notification that it did so. Otherwise, we can presume that time is wrong, and that we have to manually adjust it
The story fails to mention several key details.
1. The problem only manifests if you have a recurring alarm set.
2. The alram goes off an hour late if it was set before for DST switch.
3. The alarm goes off an hour early if it was set after the DST switch.
If the battery had not died overnight.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Not one comment yet about the real culprit here: daylight savings time. If we didn't have it anywhere in the world, then programmers wouldn't have to worry about when DST happens in different timezones (or which places have DST and which don't), or worry about what to do with log files or anything else when time jumps an hour.
Someone remind me please what we're saving? It's not electricity, because we use lightbulbs before sunrise and after sunset in summer and winter.
I use mine as an alarm clock. A few weeks ago my brother was asleep on the couch and I couldn't wake him up by calling his name, or poking him in the face, so I set the alarm on my iPhone and it woke him up.
Then take a step outside at noon
I don't know anybody under the age of thirty who doesn't use their phone as an alarm clock.
I support the Slashcott and will not be reading or commenting from 2/10/14 to 2/17/14. Beta is steaming pile of dog shit
I use a Nintendo DS as an alarm clock (because it's one of the few things I have to hand that I remember to keep the battery charged on...) and it woke me an hour early today (I'm in Europe). I wonder why the iPhone bug went the other way?
(1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
Those 9v batteries tend to run down quickly. Luckily I have a 300watt UPS lying around, which can power that device for fucking ages.
However, my iPhone is what I generally rely on. Until iOS 4.2 comes out with the patch, I just set my alarms forward 1 hour (I'm in the souther hemisphere, with the opposite problem).
This is my footer. There are many like it, but this one is mine.
People's sanity. :-P
I live in a place with DST -- basically it means in the summer, we get extra-long days so it's light until late into the evening (almost 9pm around the solstice). It shifts the hours of usable daylight into hours people might actually use during the summer instead of it being light out at 5am or something stupid.
It also makes up for the fact that in winter it's dark when you get up and leave for work, and dark by the time you leave for home after work. In winter there's a good 1.5 month period where you don't get to see much daylight -- as short as about 8h42m of daylight. DST doesn't fix this, but it gives us some of it back in the summer.
Much like you can't fathom why we have it -- if you grew up with it, you can't fathom why everyone else doesn't have it.
Lost at C:>. Found at C.
I see a lot of posts with hate for DST.. that's fine, I'd be happy if it were abolished as well.
But now back to there being a bug in how the alarm thing is handled on the iPhone. How does that bug even exist?
If the alarm is set for a particular time, say "7am".. then what does it matter whether or not the clock went back an hour at 3am?
I can understand the alarm app going a bit batty if the clock went back at 8am (essentially the alarm going off -twice- that day), but given the actual circumstances... how did the alarm decide that it should instead be going off at 8am? The clock, presumably, does give the correct time.. so it's not like its internal time functions don't know what time it actually is. I'm confused. Is this just some manner of shoddy coding going on?
What's worse is how Apple is handling it... i.e. 'not'. Most of America (some states ignore DST already) is up for its DST change next week. I guess most people are now warned by the media attention (where was that when it was NZ / AU?).
Alarm clock? I haven't needed an alarm clock for almost 4 years.
I'm sure it's merely a coincidence that my eldest child is almost 4 years old now.
There's no alarm off switch
Oh come on, don't you have a soldering iron and a disregard for warranties?
This issue is a bit more complicated than you think.
"I wonder why the iPhone bug went the other way?"
Apple - Think different.
I'm starting to think it would be easier to keep track of when Europe is NOT on holiday, rather then when they ARE.
"yes we have 7 fixed working days every year, and 3 floating work days."
Why am I picturing some crazy Rube Goldberg device which hangs a snow collection device out the window that sinks down as it fills with snow and then sets some crazy machine motion that turns on your alarm clock? ;-)
Lost at C:>. Found at C.
Hi, nice to meet you, now you do.
I USED to use my phone as an alarm clock when I was in-between houses and couch-jumping from friend to friend - all of which who still live with their parents.
All in all though - I'm terrible at getting myself out of bed. Sleep is like a drug, my semi-conscious self in the mornings will battle it out mentally on whether I can spare another 5 minutes with my eyes closed or not. My phone, being a touch device, can dismiss the alarm with a simple mash, and that'll be the end of it.
Whereas my alarm clock, even with the snooze button, will continue to go off every 9 minutes at least. I've used this to my advantage though - since I know It usually takes me hitting the snooze button 5 times before getting out of bed, I just set my alarm 45 minutes early. It doesn't make a whole lot of sense, in actuallity I get less sleep this way, but it works for me.
Point is though - phones today don't cater to this rather niche area where I want to be able to look over and see what time it is whenever, and not have to pickup my phone or anything. Likewise, I want a large snooze button, and a simple way to turn it off but not so simple you can do it without some focus.
And in before someone says "Why don't you just put your alarm clock (or phone) across the room, forcing you to get out of bed before you turn it off?"
I have tried this, and it results in me falling back to sleep on the floor and not in my bed, which isn't pleasant to wake up to.
I see a lot of posts with hate for DST.. that's fine, I'd be happy if it were abolished as well.
But now back to there being a bug in how the alarm thing is handled on the iPhone. How does that bug even exist?
If the alarm is set for a particular time, say "7am".. then what does it matter whether or not the clock went back an hour at 3am? I can understand the alarm app going a bit batty if the clock went back at 8am (essentially the alarm going off -twice- that day), but given the actual circumstances... how did the alarm decide that it should instead be going off at 8am? The clock, presumably, does give the correct time.. so it's not like its internal time functions don't know what time it actually is. I'm confused. Is this just some manner of shoddy coding going on?
I'll venture a guess:
Applications, especially ones using phone APIs, usually aren't running 24/7. At a high level, what they will do is, in some manner, register for an event with the operating system. They will then idle indefinitely until that event occurs, at which point the operating system will give the application execution time and it will respond to that event. The event can be several things, including "when the user taps the screen" and "if the phone is powered on", and notably (for this discussion) can be based off of time, such as "8 hours from now".
My guess is that, when an alarm is set, the alarm calculates the amount of time in the future until it needs to be sounded, then registers with the OS to be woken that much time later (probably via some form of nanosleep iOS API derivative). If the alarm fails to factor in DST when calculating that time difference, then it'll get its event later (or earlier, or whatever) than it was expecting, and sound (and then probably calculate the next time difference and sleep until then).
On the surface, an alarm application could register for more periodic events (clock ticks, UI update loop iterations, or just sleep for seconds at a time) and evaluate if it should sound periodically. This would have easily avoided the DST issue. The problem here is that each time the event gets dispatched, the phone has to wake up to handle it, and such periodic waking would cost unnecessary battery. In fact, the OS knows how / when / for how long to sleep based on scheduler details derived from some form of these event registrations. Applications in general (and especially on battery-consuming devices) should attempt to register for the least number of events as possible, hence (I'm guessing) why they chose the time delay calculation option instead of a periodic one.
We have, and it involves daylight savings time.
We're not making you do a damned thing. If you don't like it, don't do it. You'll just have to keep track of what time we're operating on if you need to be calling us. (And, if we need to be calling you, we need to track that.)
Are you under the impression that you are forced to have DST just because (you think) we said so? Even within North America, there are places that don't do DST.
If your own government makes you do this, bitch to them. We don't care if you change your clocks. Heck, I don't care if you even have a clock.
Lost at C:>. Found at C.
The clock is bad implementation. It should use the incoming radio signal to determine when DST is in effect, not a preset table. Sigh. Things are so bad that NIST had to come up with implementation guidelines for designers of those clocks. It is an interesting read -- most of the cheap WWVB-controlled clocks miss most of the recommendations. Case in point: my wife's clock. The things it got wrong:
1. Use of a satellite icon to mark when it's synchronized: check.
2. Insufficient signal consistency checking: yep -- every 2-3 months it completely garbles its time during synchronization.
3. Synchronization at wrong time of day: check -- time should depend on the time zone *and* time of year. The default of midnight is poor.
4. No way of turning off DST: check.
5. Display delay: check - up to 1.5 seconds off right after sync is way too much.
6. Signal quality display -- none: check.
7. Doesn't allow selection from the minimum of 7 time zones (HAST, AKST, PST, MST, CST, EST, AST): check.
I'd also add to it that since the clock has a fairly accurate temperature sensor (to within 0.2C from 10C to 50C -- I checked myself), it could easily temperature-compensate its oscillator. Moreover, it could also compensate longer-term drift of its oscillator against the WWVB, thus easily improving unsynchronized accuracy by say two orders of magnitude. It's all in the firmware, so there's little per-unit cost other than having to amortize NRE.
I haven't checked how it's implemented (MCU vs. custom silicon), but these days implementing such a clock pretty much means that you use some low-power, cheap-in-quantity MCU and do the demodulation and decoding in software, and that can be quite elaborate since the bandwidth is so low. Heck, such a clock could easily interface with pretty much all LF time code stations anywhere on Earth -- they all are in the 40-80kHz band.
A successful API design takes a mixture of software design and pedagogy.