Bug 26722 - time is wrong if hc is localtime
Summary: time is wrong if hc is localtime
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
Whiteboard: Florence Gold
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-08 20:45 UTC by Gerald Teschl
Modified: 2007-04-18 16:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-21 10:34:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Gerald Teschl 2001-02-08 20:45:34 UTC
My hardware clock keeps the time in "localtime" as opposed to "utc".
The time is set correctly by rc.sysinit at boot time but after about 15 min
it will jump by 1h (which is just the time offset for me). If I reset the
to the correct value it will be changed to the wrong value after about

Problem was not present in beta1 and beta2.

Comment 1 Glen Foster 2001-02-08 23:43:24 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 2 Michael K. Johnson 2001-02-09 22:12:55 UTC
Are you running ntpd?

Comment 3 Glen Foster 2001-02-09 23:19:06 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 4 Gerald Teschl 2001-02-12 09:58:30 UTC
No I am not running ntpd (or anything similar).

Comment 5 Michael K. Johnson 2001-02-14 00:17:30 UTC
I haven't heard this from other people, so it must be hardware-specific.
Could you please list your hardware?

Comment 6 Gerald Teschl 2001-02-16 17:14:59 UTC
This is an ASUS L7400 laptop. It is in the beta hw database #12.

Comment 7 Michael K. Johnson 2001-02-16 17:35:33 UTC
Are you using framebuffer?

Comment 8 Michael K. Johnson 2001-02-16 17:36:25 UTC
Oh, and are you suspending and resuming?

What happens if you stop apmd -- does this quit happening?

Comment 9 Gerald Teschl 2001-02-19 10:16:55 UTC
No. I use the XF86_SVGA server.

Comment 10 Gerald Teschl 2001-02-19 13:00:05 UTC
Turning off apmd makes no difference.

Comment 11 Michael K. Johnson 2001-02-21 16:29:09 UTC
Are you suspending and resuming?

Comment 12 Gerald Teschl 2001-02-22 08:54:49 UTC
Yes. But it makes no difference wether I do a suspend/resume or a full reboot.

Comment 13 Michael K. Johnson 2001-02-22 15:45:54 UTC
This sounds like an apm event setting your machine to GMT -- whether
system time is GMT or localtime is a compile-time setting for APM and
we set it to GMT.  But I assume that you are not intentionally causing
an apm event when the time jumps, is that correct?

Comment 14 Gerald Teschl 2001-02-23 09:03:28 UTC
No I am not intentionally causing an apm event.

Comment 15 Gerald Teschl 2001-03-23 15:06:15 UTC
Still broken in qa0322

Comment 16 Casey Milford 2001-05-10 13:23:18 UTC
The same issue is showing up on my laptop (DELL Latitude CPxJ PIII 650 with 256
Mb RAM) only with 5 hours (18000 seconds) instead of 1 hour.  The clock is set
back 5 hours anytime I logon.  If I reset the system time, the next time I login
to GNOME, the time jumps back by 5 hours.  This is recreatable.  Before are
entries from my boot log.  The time is correct when I boot the system.  I don't
think this is a hardware issue.  Up until three days ago I was running 7.0 and
things were fine.

  May 10 07:29:18 cmilfo date: Thu May 10 07:29:12 CDT 2001 
  May 10 07:29:18 cmilfo rc.sysinit: Setting clock  (localtime): Thu May 10
07:29:12 CDT 2001 succeeded 

I have another machine (not a laptop) running 7.1, also.  I have not been able
to recreate the problem on it.

Comment 17 Arjan van de Ven 2001-05-10 13:28:31 UTC
Are you running apmd ?
Can you use the rdate or ntpdate program to sync your SYSTEM clock
to a correct time ?

Comment 18 Casey Milford 2001-05-10 13:42:42 UTC
Yes, I am running apmd.  And yes, I have been using rdate to set my SYSTEM
clock.  I tried syncing to more than one site to make sure that one wasn't

Comment 19 jdykstra 2001-07-13 20:13:02 UTC
I am seeing the same symptoms on a Dell Latitude C600 laptop.  However, on my system I see no signs that it is related to APM.  Believe it or not, it 
seems to be caused by the X server....

After booting into single-user mode, both the hardware and system clocks show correct local time.  Switching to multi-user mode does not change this.  
However, once the X server is started (without starting an X shell, using the "X" command), the system time has now been set back by the number of 
hours my local timezone differs from UTC.  If the system is then shut down, this incorrect system time gets copied to the hardware clock by the init script.

Before determining this, I investigated APM, and found that 1) no APM events were being generated during a normal boot, and 2) the apmscript is 
correctly determining the clock mode from /etc/sysconfig/clock.  In fact, doing an APM suspend and then resume corrected the system clock on my 
machine, because the script does a "hwclock --hctosys".

Comment 20 jdykstra 2001-07-18 22:06:51 UTC
My apologies to <johnsonm@redhat.com>...this is indeed APM-related, as he indicated previously.

APM is invoked by (at least some) X servers when they start up.  APM behavior is controlled, in part, by the CONFIG_APM_RTC_IS_GMT kernel build 
option, which is set to y in Red Hat builds.

Rebuilding the kernel with this option commented out fixed the problem on my system.

Comment 21 Matthew Saltzman 2001-08-07 00:24:19 UTC
This just happened to me out of the blue.  (Also Latitude CPx-J.)

I was doing nothing with the machine, logged in and running X.  Sometime around
19:40 local time, the system clock jumped back to 15:40.  My XFree86.0.log
contains a number of lines like:

(II) PM Event received: Power Status Change
(II) PM Event received: Power Status Change
(II) PM Event received: Power Status Change

I have a flexlm license manager that noticed the problem, but no other
indications in the logs of any unusual events.

There have been a couple of these since I reset the clock and they have not
caused the clock to change again.  They seem to be occuring every couple of minutes.

The hardware clock remains correct when this happens until shutdown, at which
point the incorrect time is saved to the hardware clock.

Regarding the CONFIG_APM_RTC_IS_GMT issue, it certainly seems like a serious
problem if I need to *recompile my kernel* just to deal with my hardware clock
running in local time vs. UTC.  This says that either every customer that
dual-boots windows or every customer that doesn't will need to recompile a
kernel to have a functional system....

Comment 22 Gerald Teschl 2003-04-21 10:34:39 UTC
I do no longer see this problem.

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