From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Running RH9 on a Winbook XLi laptop. Shortly after loading battstat on the menu
bar, the system time falls behind by exactly 4 hours (to the second). The change
to the system time was verified with both the clock applet and via the "date"
command on the command line.

Even if I correct it by setting the clock back to the correct time, it will
again lose 4 hours within a few minutes. It doesn't drift, it happens instantly,
as if the clock was manually adjusted. The system does not use NTP or any other
time manipulation utility. 

Once the clock has lost the 4 hours, and I exit X, the system will lose another
4 hours once I go back into X resulting in a loss of 8 hours (to the second).
Unloading and reloading the applet alone didn't seem to have the same effect. I
had to exit and restart X.

Note that if I load the applet shortly after midnight, the clock adjusts the
time back by 4 hours and the date back by one day. For example, if the applet
exhibits this bug at 0:15:01 on October 3, the clock will change to 20:15:02
October 2. This may or may not point to an issue with timezone libraries...
although why would a battery monitor that doesn't predict runtime in minutes
care what time it is? Curious.




Version-Release number of selected component (if applicable):
gnome-applets-2.2.0-8

How reproducible:
Always

Steps to Reproduce:
1. Add battstat monitor to menu bar
2. Wait a few minutes
3.
    

Actual Results:  System lost time (4 hours) every time the battstat applet was
added to the menu bar.

Expected Results:  Certainly the clock shouldn't change. I'm not getting
younger, after all. ;)

Additional info:

It's interesting to note that this behavior occured when I was logged into the
computer under a normal user account (not root). Only root should be able to
modify the system time.