Comment 14 for bug 1095187

I believe that I've created a working fix for this bug (excerpt from an e-mail with dsglass):

------------------------------------------------
I made a few changes to /usr/bin/setalarm and after restarting the GUI and creating a new alarm /proc/driver/rtc shows the alarm set for the proper time. The method I used was more of a workaround than truly clean coding but it should work regardless of what time standard the user's machine is using.

New Code:
# Actually set alarm #

# Before we can actually set the alarm we need to account for potential
# differences between local time and UTC because the rtc wakealarm uses
# UTC regardless of how RTC is set.
utc_offset=$(expr `date -u --date "01/01/01 12:00:00" +%s` - `date --date "01/01/01 12:00:00" +%s`)

# Now we can actually set the alarm
echo $(( $wake_time + $utc_offset - $offset * 60 )) > /sys/class/rtc/rtc0/wakealarm;
echo -e "Alarm set to: $(date -d @$wake_time)"

I couldn't figure out a better way to easily get the offset of the local machine from UTC in seconds than to just subtract two dates. I'll take another look for a cleaner way tomorrow but either way this is at the very least a proof of concept that a fix is possible.

The only thing I'm not sure about is the cron jobs because I have very little experience with cron and I'm not sure how to check if they are also effected by the bug.
---------------------------------------------------------

My amended script is attached.

Just replace /usr/bin/setalarm with setalarm-workaround (and change the name) and it should work fine.

Please post back with any problems.

Eric