[citation][nom]hellwig[/nom]Delete every repeating alarm you have until we release a fix for a stupid problem that shouldn't have existed in the first place? I mean seriously, why isn't the alarm tied to the current Time? Is it 10AM on Monday? No, ok, wait and check again later.And as others have pointed out, if this was simply a problem with counting seconds or something, the alarms should have gone off early, not late. I.e. 5-hours into the day was only 4AM instead of the expected 5AM, but somehow, your alarm didn't go off until 6AM? Sounds fishy to me.This is my software engineer outrage directed at their disturbingly lax quality control (I'm in the aerospace industry, I know how to validate code). I'd be even more upset if I owned an iPhone.[/citation]
Ooooohhh, a software engineer in the aerospace industry. Well then, I guess I have to take everything you say as the gospel when it comes to programming.
I'm also a software engineer, but I work in the lowly field of embedded systems for automotive, so my opinion shouldn't carry as much weight as yours.
I have worked with countless algorithms relating to time/date calculations and I can come up with a few off the top of my head that would get "fooled" by daylight savings time. The clue lies in the fact that repeating alarms are affected but not individual alarms.
I could see a programmer dividing the week up into 10,080 minutes and having something like Sunday midnight as being 0. Each day has 1,440 minutes so to set a repeating alarm you only need an initial offset and each subsequent alarm would be "offset + (day * 1,440)". If you didn't adjust your offset using this type of algorithm, then your alarms would all be 1 hour late, just like what happened.
Of course, it's still a bug that should have been tested. But your comments like "why isn't it tied to system time" are truly ignorant and make me wonder whether you really are a programmer at all.