Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7061 - mode line clock tracks only forward system time changes
Summary: mode line clock tracks only forward system time changes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apmd
Version: 6.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-16 22:55 UTC by Joe Harrington
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-08-09 02:53:21 UTC


Attachments (Terms of Use)

Description Joe Harrington 1999-11-16 22:55:11 UTC
This applies to both emacs and xemacs mode line clocks.

When the kernel clock is set forward, emacs's mode-line clock immediately
responds.  When it is set backward, the mode-line clock stays forward until
the kernel clock catches up.  This is a problem because APMD sometimes
incorrectly sets the clock (yes it's a known problem, and no the fixes
don't work 100%), and the error is equal to your UTC offset, which can be
many hours.  So, if you are west of Greenwich, you wait for the duration of
your UTC offset until emacs's mode-line clock is correct.

I'm reporting this under xemacs too.

--jh--

Comment 1 Trond Eivind Glomsrxd 2000-04-10 15:34:59 UTC
Sorry, we are not able to fix that. To quote RMS:

*************************************************
I don't know how to fix this.  Emacs timers are controlled by the clock;
Emacs arranges to update the time display at a specified time,
calculated as one minute after now.

I don't know if there is a way to do something after a minute of
real time without relying on the system clock.
*************************************************

Sorry.

Comment 2 Joe Harrington 2000-04-10 16:24:59 UTC
Please don't give up so easily.  Most other programs handle clock updates just
fine.  You don't have to base everything exclusively on timers.  Putting an
update hook into, say, the file-save routine or something else that gets called
pretty regularly but not with each keystroke would work fine.  All it would have
to do is check the clock and test whether it was within a minute of the internal
emacs time representation, and update the timers if it isn't.  I'm sure there
are many more-elegant solutions.  Every program that I know of and that has a
time display seems to handle this just fine.  I'm sure Richard could come up
with elegant solutions if he gave it half a thought.  Tell him MSword does it
better than emacs.

--jh--

Comment 3 Trond Eivind Glomsrxd 2000-04-17 13:38:59 UTC
The problem is apmd, not emacs - the time of the system should't go backward.

Comment 4 Joe Harrington 2000-04-17 22:05:59 UTC
In an ideal world, the system time is always increasing.  We don't live in one.
I can imagine only about half a dozen other ways the time could shift.  The user
keeps the system clock in local time for compatibility with a dual-boot OS,
travels, and changes timezone.  A time server on the net has a bug and adjusts
the time forward and then back.  Someone makes a mistake typing to the date
command and subsequently fixes it.  Apmd has to do weird machinations to deal
with strange BIOSs.  I could go on.  The point is that if everyone makes just
the bare minimalist assumptions, the system falls apart.  Right now emacs is
doing that.  No other program I know does it that way, and for good reason: it
doesn't work in the real world.  A nod to robustness is required, and it's
nearly trivial to add, in this case.  See my previous post.

I wish you would stop trying to shift the blame on others and just fix the
problem, or hand it to someone who will.  This bug has sat idle here for five
months!

--jh--


Note You need to log in before you can comment on or make changes to this bug.