So who's alarm didn't go off today?

I'm sorry to disappoint the Android owners amongst us, but I cannot say my Samsung Galaxy S faired much better.

On Monday morning I received two wake up alarms, each one hour apart. The intended alarm at 6am with one previously (unwanted) at 5am.

This was certainly a result of the clock changes and I believe I have a reasonable explanation way:

I have an alarm profile set up to wake me at 6am each weekday.

It is my understanding that when an alarm is set the phone has an internal count down timer used to trigger the interrupt and hence alarm. For example, if I set an alarm at 2.50pm for 3.35pm it will interpret this as "an alarm in 45 mins time" (as opposed to "an alarm at 3.35pm). If this assumption is correct then upon the alarm on Friday it would have said "an alarm in 48 hours time" ready for the next alarm of that type (i.e., the next week day morning - Monday morning). In reality with the clocks changing this caused an early alarm. Upon the early alarm and its resetting for the next weekday occurrence of 6am it would have realised that this was in one hours time and said "an alarm in 1 hours time" and hence the "correct" alarm was also set.

Essentially the problem is that the alarm considers the time delta (difference between the time the alarm is set and the time the alarm should sound) at the time of setting the alarm. This means that if any daylight savings happen in between they do not change the alarm. Of course, I'd imagine there is some consideration for this in the operation of the phone (for example when manually change the time) but I assume this check is (accidentally) omitted in the case of the clock being automatically changed (in the instance of day light savings changes, for example).

I'm not sure if my assumptions are correct, or if my arm waving arguments are well expressed but I think this may suggest the reason for the problem. Then again, I guess this was more fortunate than the iPhone users in any case - at least my alarm was too eager to trigger, rather than not at all. :p
 
Just thought about it again, surely what I wrote above is correct?

Let's walk through it:

-> 6am alarm on Friday
-> Phone sets alarm for + 72 hours
-> Therefore, alarm set for 6am Monday
-> But clocks went back by one hour, so "old" 6am on Monday is now 5am on Monday

The other way to look at it is that the "count down timer" was set to 72 hours, but because the clocks went back it effectively counted down one hour twice [the time we reverse the clocks by 1 hour] (in the same way we have one extra hour in bed), therefore it is really a net difference of 71 hours.

Eg, 6am alarm on Friday -> 5am alarm on Monday

Is this right now? Between the two of us I've confused myself now :p

EDIT: Modified 48 to 72 (initial mistake, but didn't affect logic)
EDIT2: May be easier to think about it the other way around:

How many hours are there between 6am on Friday and 6am on Monday? 72.
Now if we move the clock back by one hour on Sunday morning, how many hours are there between 6am on Friday and 6am on Monday? 73.

The phone set it's count down from 72 which meant it sounded one hour early.

There is still a (large) chance that I'm wrong, so please highlight it... but it seems to make sense to me at the moment...
 
Last edited:
I very much doubt it sets the alarms using a countdown timer. It'll be done the same way that most times are done on Unix based computers - it'll be saved as the time since a given epoch, in GMT, and then offset for the difference between GMT and your particular timezone. Both iOS and Android have their roots in Unix systems, and that's how Unix does things.

It sounds like the problems with iOS have arisen because the time is being stored using a fixed timezone offset that doesn't take account of BST/GMT. I'd imagine that the same thing has happened with the Galaxy S, though I can't readily think of why the alarm would go off twice.
 
vonhelmet said:
I very much doubt it sets the alarms using a countdown timer. It'll be done the same way that most times are done on Unix based computers - it'll be saved as the time since a given epoch, in GMT, and then offset for the difference between GMT and your particular timezone. Both iOS and Android have their roots in Unix systems, and that's how Unix does things.

It sounds like the problems with iOS have arisen because the time is being stored using a fixed timezone offset that doesn't take account of BST/GMT. I'd imagine that the same thing has happened with the Galaxy S, though I can't readily think of why the alarm would go off twice.
Click to expand...

Makes more sense. Though I'd have thought the problems with iOS and Android would have been similar rather than one hour early (on Android) and not at all (or late?) on iOS.
 
You must log in or register to reply here.
Back
Top Bottom