Well, system time is kept in UTC for many goodreasons so it is the alarm that needs to be rescheduled by one (UTC) hour if user 'doesn't expect a change at all'. See the bugzilla entry for more details.
But the alarm doesn't need to be rescheduled; it could be initially scheduled for "every day at 0700 local" rather than either "at 0700 local and every 24 hours after that" or "every day at 1200 UTC"; storing timezone info as part of the alarm seems like the "right thing", and I don't think the performance hit for doing it that way should be troubling. (Then again, I don't know anything about the implementation of the alarm system; maybe there is some cleverness used to save overhead that couldn't work otherwise...)
Obviously it's even more work to do it that way than to put an hour-shifting patch in, and it's not clear what's to be gained beyond elegance. (Maybe edge cases when an alarm is set for that chunk of 0dark30 elided by DST in the Spring, and whether or not the analogous Fall alarm doubles...)
Obviously it's even more work to do it that way than to put an hour-shifting patch in, and it's not clear what's to be gained beyond elegance. (Maybe edge cases when an alarm is set for that chunk of 0dark30 elided by DST in the Spring, and whether or not the analogous Fall alarm doubles...)
World's first inductively-charged N900!