Comment 16 for bug 1095187

Thanks for the patch, and for working with me on this.

However, I don't think that using hwclock with fix the problem. While troubleshooting this program originally I played around a lot with my hwclock and as a result I now have it set in local time and this didn't help fix WakeUp. The problem is that regardless of how you keep your BIOS time or your system time there is no mechanism in hwclock to tell you which it is set to. As it says in the documentation:

 --localtime
              Indicates that the Hardware Clock is kept in Coordinated
              Universal Time or local time, respectively. It is your choice
              whether to keep your clock in UTC or local time, but nothing in
              the clock tells which you've chosen. So this option is how you
              give that information to hwclock.

              If you specify the wrong one of these options (or specify
              neither and take a wrong default), both setting and querying of
              the Hardware Clock will be messed up.

              If you specify neither --utc nor --localtime, the default is
              whichever was specified the last time hwclock was used to set
              the clock (i.e. hwclock was successfully run with the --set,
              --systohc, or --adjust options), as recorded in the adjtime
              file. If the adjtime file doesn't exist, the default is UTC
              time.

So the default is UTC even if your BIOS is in local time and there's no way of knowing how hwclock is set.

I tested the new hw_offset variable as: expr `date -d "$(sudo hwclock)" +%s` - `date +%s` and I got "-3" as opposed to -18000 which is the proper offset for me to UTC.

I think that you would be better off (as you proposed in an e-mail) using date +%z to get the offset from the TZ environmental variable (I'm guessing that the user is required to set that during installation so I think that's pretty safe).

Eric