[kwlug-disc] OT: Apple's iPhone iPad etc Daylight to Std time bug
unsolicited at swiz.ca
Sat Nov 6 15:34:17 EDT 2010
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
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.
More information about the kwlug-disc