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