Bug 7062 - mode line clock tracks only forward system time changes
mode line clock tracks only forward system time changes
Status: CLOSED DUPLICATE of bug 59994
Product: Red Hat Linux
Classification: Retired
Component: apmd (Show other bugs)
6.2
All Linux
medium Severity low
: ---
: ---
Assigned To: Ngo Than
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-16 17:56 EST by Joe Harrington
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-11 14:14:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 1999-11-16 17:56:21 EST
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 emacs too.

--jh--
Comment 1 Tim Powers 1999-11-22 09:26:59 EST
Thanks for letting me know about this. I'm getting with the emacs package
maintainer about this.
Comment 2 Trond Eivind Glomsrxd 2000-07-10 16:59:28 EDT
Time shouldn't go backwards according to Stallman - if so happens, it's a bug in
APMD.
Comment 3 Joe Harrington 2000-07-10 18:29:52 EDT
I'll repeat my comments from bug 7061:

 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.

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.

I'm sad to see Red Hat diddle its thumbs for 8 months not doing anything, then
blame someone else and give up.  This would be so simple to fix.  Just read the
system clock every time a file saves, or 1000 keystrokes happen, or some other
semi-regular event occurs.

--jh--
Comment 4 Trond Eivind Glomsrxd 2000-07-11 14:14:44 EDT
If a user swiches timezones, it won't be a problem because the kernel keeps the
UTC internally. This should not move backwards - if apmd does that, it's an apmd
bug.
Comment 5 Bernhard Rosenkraenzer 2002-02-26 12:29:07 EST
 

*** This bug has been marked as a duplicate of 59994 ***

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