Hi,
I frequently use suspend-to-ram (S3 / STR) when I am away from the computer for
a longer period (and it has nothing to do). The timers are NOT reset or even
stopped when the computer is in STR. So when I placed my PC in standby and got
back 2-3 hours later I had work for that time (according to WorkRave), it also
said I pulled an all-nighter (effectively working ~16 hours from 8.00 am to 8.00
am, I can assure you, I didn't) and my rest-period was >9 hours overdue.

My guess is the same goes for S1 and Hibernate, but I do not use those.

Suggested fix (not really a fix, just some thoughts):
- somehow detect computer goes to standby (mouse and keyboard are not reporting
any activity).
- I guess there is some kind of system-wide OS-command, that tells all programs
the PC is going to standby (or comes back from standby). But I am not sure, and
absolutely do not know what it is, I could be sadly mistaken. Outlook seems to
use it (it always sends/receives right after a standby, that is longer than the
interval).
- crude method: reset all timers at the day-limit reset time. Not a good method
(=understatement), since not every standby 'passes' that limit, but probably
very easy to implement.

I hope this info helps.

I said: PC, all windows versions, but I am not sure. Could be just XP (I doubt
it) and it could very well affect other platforms as well.

I sometimes use suspend-to-disk (on XP), basically because I'm too lazy to
restart all my applications when I arrive at work in the morning.

I have not yet seen the behaviour you describe. When I restart the computers all
timers are always reset exactly the way I expect.

To arrive in suspend-to-disk mode, I use a keybord shortcut on my laptop,
instead of choosing "shutdown" form the start menu. Hence, at the time of
suspend-to-disk, wr probably does not consider me active. I do not fully recall
all the details of activity detection, but this might have something to do with
it :-)

Any other thoughts??

I use the sleep button on my MS-keyboard. But maybe it does work ok with
suspend-to-disk and only fails with suspend-to-ram? (like I said, I do not use
hibernate).

I did some extra tests; I think the solution could be simpler than I originally
thought.

When I go to STR (with the sleep button) with the me being idle the timers DO
stop (or better: stay 'stopped'), but if I'm not idle (or at least not yet ~5
sec idle), the counters continue to run. Since going to STR takes like 1 second
that’s not enough to 'make me idle', hibernates probably takes over 5 seconds
(so you are idle using that).

I cannot easily reproduce your problem. I am currently unable to
"suspend-to-ram".  No matter what I tell XP to do (either "slaapstand" or
"standby"), it always suspends to disk.

At one point, I noted some odd behaviour, just after resuming from disk:
micropause and restbreak timers did show some activity, but otherwise did not run. 

Apparently I was neither active nor inactive (micropause timer didn't run, but
also didn't indicate a natural break). 

After a while of being inactive, wr started to indicate I was taking a natural
break.

I take that back. There is definetly something odd here. For yesterday, I have a
daily usage (according to the statistics window) of 20:34 hours, yet no overdue
time (with a daily limit of 2:30 hours :-).

Also, the statistics window reads "Datum: 25-3-2003, van 10:36:00 tot 11:33:00".
Apparently this indicates a period of 25 hours. Considering that I left the
office at about 17:30, that would mean that of those 20:34 hours daily usage, I
spent 18 hours in "suspend to disk", and a little under 2:30 hours actual usage,
which sounds about right.

See bug #229.

Hopefully fixed (again see bug 229)

There is still something odd here. I suspended to disk last saturday, and
started up again today. Wr (1.2.3 alpha, I believe), however, is convinced that
it is still saturday, and is happily adding my activity there.

So when I open the statistics window, the date widget starts at today, but finds
no recorded history, Then, when I click left arrow, I end up on saturday, seeing
my activity being increased.

I have not yet succeeded in convincing wr that it is monday (then again, I would
prefer it being saturday too).

Indeed. should be fixed now.

I am using 1.4.0 now. it does stop the countdown of the timers, but it does not
reset them (when WR is not idle while suspending).

So if WR is idle it works okey (so did 1.2.2); but if the timers are still
counting-down they are stopped by suspending but not reset (suspended longer
than restbreak is not counted as a restbreak, same for minibreaks).

I have not yet tested overnight suspend.

Forwarding the time as in
http://www.workrave.org/cgi-bin/bugzilla/show_bug.cgi?id=229 has the same effect
(timers are stopped, but not reset), but in that case it probably is the desired
effect.

Correction: it seems the restbreak timer is not reset after standby, even if the
WR was idle (timers not counting down).

If WR is idle and PC is standby overnight, the timers are reset (I have not yet
tried overnight standby without WR not standby).

I made some errors in previous post (timers on overnight suspend probably were
reset before suspend, not during).

To make it clear:

* Suspend PC with timers running:
- Now: timers are stopped but not reset.
- Expected: timers reset if idle time was longer than breaktime. If suspend was
not as long as the break it should could as part the break (but this is not as 
'important' as first remark).

* Suspend PC with timers stopped:
- Now: timers not reset.
- Expected: timers reset if idle time was longer than breaktime.

* Suspend PC overnight with timers stopped or running (no difference):
- Now: only daily limit is reset, restbreak and minibreak are not (they are
stopped if they were still running).
- Expected: all timers reset (since my break was long enough).

So there is practically no difference between timers running or stopped (this is
good), but some improvements can be made. When I want to take a longer break
(and place my PC in standby) I now have to: wait a restbreak before or after
that break (otherwise the timers are not reset), or I have to Skip a restbreak.
Overnight about the same: a restbreak before or after the suspend.

When workrave detects a gap in time (because of STR or a change of system time)
Workrave assumes that you became idle at that time and assumes that the skipped
time never existed. In other words, during this time you are neither active nor
idle. Although this behaviour is desired if you change the system time, it is
not if in case of STR.  

I don't see a way to distinguish STR and a change of system time (unless the
clock is set back). I propose to change the current behaviour: assume that you
become idle at the moment the time-gap starts. In case the time is set back, we
keep the current behaviour. Disadvantage: When you set the clock forward,
workrave assume you were idle during this time...

Comment? Ideas on how to detect STR/change of system time?

Well, since the daily limit IS reset overnight, the other timers could be reset
as well (at least on overnight suspend). But this will reset the timers for
people who change the DATE of the PC (but than again changing the date resets
daily limit also).

About the daily limit: if I set the Date to tomorrow: the daily limit is reset
if I return to today the daily limit is STILL reset and WR still thinks it is
tomorrow (even after a restart of WR; I did not restart the PC).

Ideally, you'd want to have a second timer that keeps running during suspends,
but is not affected by changes of system time. I don't know much about hardware,
but I expect such a timer to be there.

Alternatively, you could investigate if windows sends a signal when suspending.
I bet there is one. Other applications should have similar problems when dealing
with suspend.

It seems there is an event: WM_POWERBROADCAST. 

Fixed. Workrave now detect the difference between setting the clock forward and
powersave. Please try http://workrave.org/files/workrave-1.4.1-pre4.exe (or
workrave-1.4.1-pre4-debug.exe if you want trace logging)

This is not a full installer. Just copy the executable to \Program
Files\Workrave\lib and run this executable instead of workrave.exe

About the "set the date to tomorrow and back to today" problem: this is not
fixed, and probably will never be. I think it's not worth the trouble. This
would require workrave to revert quite some things (timers, statistics,
statistics history...). Just don't do it :-)

*** Bug 297 has been marked as a duplicate of this bug. ***