[xmonad] xmobar time stops when system clock turns back

Spencer Janssen sjanssen at cse.unl.edu
Wed Feb 13 06:16:13 EST 2008

On Wed, Feb 13, 2008 at 10:40:57AM +0100, Andrea Rossato wrote:
> On Tue, Feb 12, 2008 at 05:37:11PM -0500, Adam Vogt wrote:
> > I guess that this place is the best to report this issue:
> > 
> > You just have to set your clock back a couple seconds (or more), and the 
> > time display doesn't update immediately. Going forward is fine.
> > 
> > I think that when you pass the time that is 'stuck' on xmobar, it sometimes 
> > starts updating again.
> > 
> > Not that this is much of a problem, I think that it is still a bug, the 
> > workaround being to restart xmobar.
> It's always a problem when the system times is brought back (since
> that system is going to live twice the same moments - dovecot, my imap
> server, is going to exit). But the xmobar behaviour is unexpected.
> I think this is a bug that is deeper than one may think at first, and
> it does not involve just the date plugin. Maybe something related to
> STM?
> I don't know and I need to investigate.
> Since there are another few bugs I need to take care of, I opened a
> bug tracker at code.google.com:
> http://code.google.com/p/xmobar/
> I hope I'll be able to fix it rapidly.
> Thanks for your report.
> Andrea

This is an issue in GHC, I think.  threadDelay must check the current
system time, then the thread isn't run until system time reaches
(initial time + wait time).  Of course this might be a large amount of actual
time if the system clock is turned back after threadDelay is executed.

Spencer Janssen

More information about the xmonad mailing list