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."

Comments

Re:Is this story for real?

[ais523]

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?

Hate for DST aside, how does this bug even exist?

[Animaether]

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

[tibit]

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.

Re:Real bug: changing the time

[Aqualung812]

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.

Mother Nature doesn't let you bullshit the numbers and bail you out afterwords.

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.