iPhone Alarm Bug Leads To Mass European Sleep-in 487
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."
Re:Not just iPhone 4s (Score:2, Interesting)
If it were subsidised, I would like you to say it.
Re:Is this story for real? (Score:1, Interesting)
I work rotating shift work with a lot of overtime, so my phone is one among several of my alarms (including my watch and two alarm clocks). I'm also a very heavy sleeper, so I need a lot of agitation to get me up. In total, I have 3 alarms on my watch, 6 on my phone, and 2 on each of my alarm clocks. I need them all.
Re:Responsiveness.... (Score:3, Interesting)
I only ask this because a while back Apple said that they had already paid out $1 billion to developers. Considering that not all apps cost money and that this doesn't include data from Android phones, which have (or will in the near future) similar numbers of sales, it would appear as though there is a lot of software that people want to use.
Re:Is this story for real? (Score:5, Interesting)
Hate for DST aside, how does this bug even exist? (Score:5, Interesting)
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?).
Re:Another day (Score:3, Interesting)
A buddy had a UPS with the beeper that you couldn't shut off. We found a wood screw and jammed it in the speaker hole. As he turned in the screw it got quieter and quieter until it finally quit. If you back the screw out, it will beep again.
How many billions did that cost? (Score:2, Interesting)
Europe is not exactly known for its stellar productivity per capita per hour rates, but I still can't imagine that Apple's negligence didn't still cost $Billions.
It's too bad the time change isn't in August when Europe isn't producing anything. The effect would have been nil.
Re:Hate for DST aside, how does this bug even exis (Score:3, Interesting)
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.
Not at all. The problem here is that if you want an alarm at 8am every morning, that's always 24 hours after the previous time, except one day where it is 23 hours later, and one day where it is 25 hours later. How you measure the time is irrelevant, as long as you know that on this one day the alarm must come after 23 hours and not 24.
Re:Another day (Score:3, Interesting)
There is an abomination of an AC clock silicon that has been on the market for 2+ decades it seems. The time keeping is synchronized to the mains when mains is present. When there is no mains, there is an RC oscillator that runs fast. Why? Because some harebrain put those values on the application circuit in the datasheet. Everyone uses that silicon, and they all copy the app circuit verbatim without ever bothering to check how fast the RC oscillator works. Thus all those clocks behave like that. Moreover, the 9V battery lasts a really short time when there's no mains. 1-2 days at most it seems. Heck, it may even be a bipolar or an NMOS design, or so it'd seem from the performance.
I hope someone at the chip maker retired that design. Like lost the tapes/files and all documentation, and gave a blank stare when someone would mention it. One can dream.
The truth is that anyone can make a way better performing clock using a single chip power-conscious MCU like MSP430 or Parallax Propeller. It'd even be fully functional when running off battery -- perhaps with the display turned off by default and available when you press any UI button.
Re:Another day (Score:5, Interesting)
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 [nist.gov] 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.
Re:Is this story for real? (Score:2, Interesting)
How do you get 9 hours of in-bed time when you've just gotten home from work, haven't eaten in 9 hours, and have to be up to get ready to go back to work in 5 hours? I mean, without breaking the laws of physics.
Re:Or at least it would have... (Score:3, Interesting)
If the battery had not died overnight.
Fortunately, before the battery went flat, my N900 had powered itself off when there was still enough juice on the battery to wake up for a few alarms... :p
Re:Real bug: changing the time (Score:4, Interesting)
If they aren't at home, the air conditioning or heating costs will be elsewhere.
Incorrect. If they are elsewhere, it is frequently the case that the "elsewhere" continues to cool the building regardless if the person is there or not. Schools continue to cool for teachers staying late, factories often work 24/7, retail places are open well after people would be home.
If by bullshitting the numbers you mean writing down factual electric meter readings and performing simple math (as TFA said), then I'm curious to hear how Mother Nature does her math. This wasn't a guessing game, the sum total electric use in Indiana increased at the same time DST was introduced. They even used the counties that were already on DST as a control group (for weather, more TVs, whatever), so don't even try to go the "correlation is not causation" route.
Re:DST? Which century are we living in? (Score:2, Interesting)
Because, everything else around us won't change.
We still have to schedule everything else with the world around us...
Right, just like everyone around us doesn't change via DST...or wait, some of us change, some don't, according to regional preference...much like it would be if operating hours shifted instead of clocks...so what's your argument again?
... and, quite frankly, I don't want to feel like I'm getting up at 5am to go to work.
So...the number shown on a clock immediately convinces you that it's later than what your body thinks it is? Seriously?
We mostly view your suggestion of change the working hours as a dumb idea.
Ditto to 'your' DST idea.
Re:Not just iPhone 4s (Score:3, Interesting)
I have a Samsung star 5233 and I put it face down on my bedside table. The two call buttons on the front protrude just enough that I can snooze it by pressing on the back of the phone, no accuracy needed. Just a good klap on the back and it is back to dreamland...
Re:Not just iPhone 4s (Score:2, Interesting)
Since when is $99 99 euros? An $140 android phone is not is impressive.