I have this problem bith with the regular clock-applet and with the
afterstep clock, so it's probably somewhere in soem code they share.
The easiest way to reproduce it is:
set clock forward with date -s
wait for clock to catch up.
set clock back to real time.
clock doesn't catch up untill the time passes the time it was set forward
This is might seem a small bug but for some reason the clocks also
decide to jump an hour forward after each suspend / resume cycle.
(probably has something todo with my time zone which is gmt-1)
I think that if the simple problem is fixed the complex problem will be
hidden, but I don't care as long as my clock shows the correct time.
And then it takes an hour before it show a usable time again, if my laptop
/ system doesn't suspend before that.
This has finally been fixed, and was just put in Rawhide.
I just tried gnome-core-1.0.55-7 (dated 02/09/00)
And this bug still seems present both in the normal and Afterstep clock, I used
the method described above to make the clock freeze.
Sorry, I should have been more clear. The bug was in gtk+, so try upgrading
that see if it fixes it. If this doesn't fix it, reopen the bug, and we'll try
to figure it out, but it seems to work here. (TM)
I still have the problem with gtk+-1.2.6-5, the latest I can get my hands on, in
which version should it be fixed?
Running with the latest gnome-core gnome-libs and gtk from the snapshots dir on
ftp.beta.redhat.com I still have this problem. Even worse if I now set the time
backwards not only the clock freezes, but also sawmill.
I do get a few heuh time seems to be traveling backwards messages in my Xlog
Okay, this bug is fixed for me in the 4 march snapshot, so I'm closing it,
the sawmill problem still is there, but the clock problem is gone.
So I'll open a new bug report for sawmill.
In the meanwhile I'm closing this one.