Hide Forgot
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 too. 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.