[kwlug-disc] OT: Apple's iPhone iPad etc Daylight to Std time bug

[unsolicited]

John Johnson wrote, On 11/06/2010 1:01 PM:
> At 12:46 2010-11-06, William wrote:
>> Of course, internal clock is UTC.
> 
> The problem is with the alarms, e.g. wake up, appointments, meetings, 
> etc., especially regularly, recurring alarms that span the transition 
> from xDT to xST. The problem is moving westward with the sun, starting 
> in Australia.

Agreed, but the problem is more than that.

[And you know the dangdest things, John! Do we need to strike (ah 
hah!) another government committee to make sure similar problems 
aren't going to occur with the new fighter purchase? I can't believe 
they didn't simulate such a flight on the ground beforehand. Wait ... 
they probably did ... and the supervisor simulator program is also 
broken ...]

Some alarms need to be set by specific time, some need to be set by 
delta (from midnight), some need to be set by different criteria. 
Alarms by duration vs. alarms by moment in time - and rather than 
start another timer, you delta the time between then and now - getting 
all confused when time goes backwards (cause you delta'ed the time, 
not the time and date).

Yet the storage of these triggers goes through the same code without 
distinguishing. It would be convenient to blame programmer laziness, 
however I expect other constraints come into play.

Is this really any different than the year 2000 problem?

Doesn't it really come back to ... programming of the time had to be 
mindful of ram / cpu / resource constraints, that probably do not 
apply today. Instead we have people / time constraints, so lift, 
rather than rewrite, code.

Maybe reinventing the wheel does make sense after all.