Wakeup wakes computer at incorrect time

Can you include
1) a copy of the output of `sudo crontab -l`
2) ~/.wakeup/alarm0/wakeup_settings. Note: this file contains the text of your alarm, so for privacy you may want to edit/remove the corresponding line.

Thank for your answer.

"31 6 20 12 4 /usr/share/wakeup/setnextalarm.py helion >/dev/null 2>&1
@reboot /usr/share/wakeup/setnextalarm.py helion >/dev/null 2>&1
31 6 20 12 4 /usr/bin/wakeup helion 0 >/dev/null 2>&1 #entered by setnextalarm
"

Do you want me to try again to see if the problem is still there?
I can purge and install again and try?

Can you tell me, after you press "Apply" in wakeup, what the output is of: $more /sys/class/rtc/rtc0/wakealarm. Also, if you run wakeup-settings from the command line, do you get any errors when applying the alarm?

I have "1357947300" in /sys/class/rtc/rtc0/wakealarm after having applied a new alarm.
I have no error in my terminal when applying a new alarm.
I will see tomorow if the problem happened again.

I take based on the other bug you filed that you are in France, this looks like the time set is midnight for you. What does the dialog say when you press apply? Next alarm at....?

I am not in France, I am in Laos for one year. The dialog window says : "All alarms set successfully. Next computer wakeup at: samedi 12 janvier 2013, 06:41:00 (UTC+0700)

Everything seems good.

Hm,well then that shouldbe right, and it still boots at midnight?

Let see tonight. If there is a change.

Still there. The computer started at 23:36:24.

Check what time your bios thinks it is. The boot time is correct, but for UTC. What model computer do you have?

I also have this problem.

I set my alarm for 10:45 and the computer doesn't wake. I went in and checked $ cat /proc/driver/rtc and found that the alarm was set for 15:45:00. This bothered me so I downloaded the source for WakeUp and looked it over.

I believe that the problem comes from the fact that I keep my hardware clock in local time because I dual-boot Windows on my machine. And even when RTC is in local time the rtc wakealarm still needs to be given in UTC time.

I believe that the problem originates in /usr/bin/setalarm.

I'll post back with more details if I can.

Thank you dsglass for this awesome app!

Eric

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

Thanks Eric for your help on tracking this down, and posting your fix. I believe that as given, though, setalarm would give the wrong time for people who do have their hardware clocks in local time. Instead, I modified the script as follows:

# Account for hardware clock vs UTC mismatch
hw_offset=$(( $(date -d "$(sudo hwclock)" +%s) - $(date +%s) ))

# Actually set alarm #
echo $(( wake_time - offset*60 + hw_offset )) > /sys/class/rtc/rtc0/wakealarm

I have attached a patch. Apply by running `patch /usr/bin/setalarm setalarm.patch`.

It would be great if folks with their hardware clcok in either utc or local time could test this out. If it works, I'll push the update to the code trunk.

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

Hm, I do not follow this exactly. Running expr `date -d "$(sudo hwclock)" +%s` - `date +%s` for me gives -28800, the same as both the time zone method and your previous method. What are the outputs for you when you just run hwclock, and when you run date? Although hwclock doesn't know whether it is in local or utc, you can tell by comparing to system time, and that really should be all that matters.... As I noted, just relying on time zone data will not work if your hardware clock is already in local time.

David

Upon further examination of the other proposed fix:

# Get Time zone offset. As of Ubuntu 12.10, the wakealarm file is time in UTC.
tz=$(date +%:z)
tzhr=${tz:0:3}
tzmin=${tz:4:2}

# Actually set alarm #
settime=$(date -d "$(date -d @$wake_time) +$tzhr hours +$tzmin mins - $offset mins" +%s)
echo $settime > /sys/class/rtc/rtc0/wakealarm

I think that this may also have a problem.

date +%:z returns a numerical value that can be either positive or negative, but the substring tzmin doesn't preserve the sign value of tz so, for users with tz < 0 and tzmin /= 0, $tzhr hours + $tzmin mins will give an incorrect value.

For example:
tz=-05:31
tzhr=-05
tzmin=31

So,
$(date -d "$(date -d @$wake_time) +(-05) hours +31 mins" +%s) /= $(date -d "$(date -d @$wake_time) +(-05) hours +(-31) mins" +%s)

I'm not certain of the best way to address this yet but I'll keep thinking.

There is also another small problem with the sign which is, if tz > 0 then tzhr will have a colon in it. I'm not sure if this is really a problem or not but I thought it was worth pointing out.

Eric

$ date && sudo hwclock
Sun Feb 3 17:53:30 EST 2013
Sun 03 Feb 2013 05:53:28 PM EST -0.582869 seconds

Hmmmm, I think it is I who is not following now.

I don't understand what you mean by " just relying on time zone data will not work if your hardware clock is already in local time." My hwclock is in local time and I get the proper value of -05 with date +%:z.

I believe that the timezone of the hwclock has no bearing on the bug with WakeUp. As rtc wakealarm only accepts times in UTC the only thing we are concerned with is the difference between the time the user wants the alarm set to (presumably expressed in their local time), and UTC time.

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.

I be happy to test the solution. How can I do that?
I have wakeup 1.3

Download the following setalarm.patch and apply by running (from the folder you downloaded the patch to):

sudo patch /usr/bin/setalarm setalarm.patch

Thanks!

The patch didn't work.
The BIOS's time and the system time is the same. I am in the UTC+7 time zone.

THe computer didn't event wokeup at midnight. But when I set an alarm and I don't turn off the conputer the alarm works.

Can you post what you get from the commands:
1) sudo hwclock
2) date
3) date -u
and after setting the alarm,
4) cat /sys/class/rtc/rtc0/wakealarm

This would help figure out why it's not working on your system. Thanks!

helion@helion-PC:~$ sudo hwclock
[sudo] password for helion:
jeu. 14 févr. 2013 19:23:41 ICT -0.891943 secondes
helion@helion-PC:~$ date
jeudi 14 février 2013, 12:23:56 (UTC+0700)
helion@helion-PC:~$ date -u
jeudi 14 février 2013, 05:24:01 (UTC+0000)
helion@helion-PC:~$

There is nothing in /sys/class/rtc/rtc0/wakealarm

I think the mistake is in the -u. Based on re-reading the manpage of hwclock, apparently hwclock reports time in local time zone, which means my first idea may have been the right one. Can you try removing the "-u" in the line "hw_offset=...." in /usr/bin/setalarm, and re-running, testing if the alarm goes off, and checking the content of /sys/class/rtc/rtc0/wakealarm? Also, I had trouble converting the date format you get out of hwclock. Does running `date -d "$(sudo hwclock)" +%s` give you an error?

I am going to see for the alarm:

helion@helion-PC:~$ date -d "$(sudo hwclock)" +%s
[sudo] password for helion:
date: date non valide «ven. 15 févr. 2013 00:05:47 ICT -0.359893 secondes»
helion@helion-PC:~$

So there is an error.

So the new (i.e. without the -u didn't work for the boot but stile works when the computer is on)
and stile noting in /sys/class/rtc/rtc0/wakealarm

Yeah, wakealarm won't be set if that gives you an error. Unfortunately that's a bug in the 'date' utility, it doesn't recognize "ICT" as a time zone. We can work around that, though. We'll have to just remove the time zone tag from the output of hwclock, since it's actually unnecessary. Try replacing $(sudo hwclock) in that same line with $(sudo hwclock | sed -r 's/[A-Z]+\s+([0-9\.\-]+)/\1/') and see if that works...

Helion,

Could you please set the alarm through Wakeup and then post what time you set the alarm for and the output of:
cat proc/driver/rtc

The next time you reboot your computer could you also please go into the BIOS and see what time and date the BIOS thinks it is. and then post that time and the time and date where you are.

Dsglass and I have differing opinions as to where the issue lies with Wakeup. He believes that the problem has something to do with the offset between the hwclock and the system time. I believe that the hwclock is irrelevant and that the problem only has to do with how we write the alarm time to /sys/class/rtc/rtc0/wakealarm

Eric

Eric,

Have you tried my recent attempt? (no -u, possibly sed away the time zone from hwclock if your time zone isn't recognized by date)? For me this works, /sys/class/rtc/rtc0/wakealarm looks like it has the wrong time, but my computer wakes up at the planned time.

Any updates on this folks? Is there something I can do to move this along - it would be great to get this out in time for the next Ubuntu release (mid-April I believe).

After looking into the details of how Ubuntu maintains the hardware vs. system clock, I believe I have fixed this - you do need to check whether the hardware clock is kept in UTC or not, but time zone also comes into play. Basically, setalarm normally calculates the wake time in UTC (date +%s), and so if the hardware clock is in UTC, setting this time directly works no matter what time zone you are in. If the hardware clock is in local time, the /sys/class/rtc/rtc0/wakealarm file still requires UTC, so the wake time must be converted by the time zone offset. The new code checks whether the hardware clock is in UTC by comparing the hour and minute recorded in /sys/class/rtc/rtc0/time to that provided by `date +%H:%M`

I have tested the following changes to setalarm with my computer set to UTC and local time, in multiple time zones (including ones that are not whole hours, such as +530). It works across the board. Please comment if it does not work for you. I'm attaching a patch, which can be applied to the original setalarm file from wakeup-1.3 by running `sudo patch /usr/bin/setalarm setalarm031914.diff`