Comment 20 for bug 1095187

You are right about the fractional time zone mistake, but I believe the hardware clock is the real problem. I think I know what the problem is, though, if the hwclock solution doesn't work for you. The variable wake_time is the time the computer should wake up (other than the 5 min offset) in UTC. So really the line I added should read (notice the additional -u):

 hw_offset=$(( $(date -d "$(sudo hwclock)" +%s) - $(date -u +%s) ))

The idea is this:

Your system time (the time you see on your desktop) is your local time. Wakeup determines what time you want your computer to wake up in this time (system time / local time). This is also the time reported by `date`.

Your hardware clock (BIOS) is what the computer keeps track of when the machine is off, and so what determines when to wake up when set by setalarm. This is the time returned by hwclock, and may be either UTC or local time.

For example, for me,
1) `date` yields: Sun Feb 3 15:21:47 PST 2013
2) `sudo hwclock` yields: Sun 03 Feb 2013 07:21:55 AM PST -0.844114 seconds
3) `date -u` yields: Sun Feb 3 23:21:47 PST 2013

Since wake_time is in utc, (2) - (3) added to wake_time should give the wakeup time in hardware time. (For me, (1)-(2) happens to be the same as (2) - (3), hence my mistake in missing the -u).

The problem with using date +%z is that this refers only to the system time. So: if your hardware clock is kept in UTC, then wake_time is already correct for the hardware clock, and adding a time zone offset will cause the computer to wake up at the wrong time, instead of fixing a non-existent problem.

Let me know if the fixed version works. For me this solves the problem.