Bug 709924 - Time jumps backwards on reboot.
Summary: Time jumps backwards on reboot.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 15
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-02 01:43 UTC by Jim
Modified: 2014-03-17 03:27 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-20 10:10:46 UTC
Type: ---


Attachments (Terms of Use)

Description Jim 2011-06-02 01:43:55 UTC
Description of problem: If the system BIOS uses local time instead of UTC (e.g. with a dual boot Windows system) the clock is set to an incorrect time when Fedora boots. (This is basically a reopening of Bug 447019 against Fedora 15. I'm new to Bugzilla. I apologize if this is not the correct way to reopen a closed bug.) 

Version-Release number of selected component (if applicable):
initscripts-9.30-2.f15.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Ensure "System clock uses UTC" is NOT checked in Data/Time app
2. Ensure that time zone is set to New York.
3. Note time displayed in date/time of gnome3 desktop.
4. Reboot and log in. 

  
Actual results:
Time displayed in date/time of gnome3 desktop is 4 hours earlier then before the reboot.

Expected results:
Time should be about the same as before the reboot.

Additional info:
Not sure whether initscripts is the correct component. I specified that because that was the component specified in bug 447019.

The BIOS clock is being reset at some point to the earlier value. If I check the BIOS clock during boot up, it will be 4 hours ahead of what gets displayed in date/time after boot up completes and 4 hours earlier than what it was at the previous boot up. 4 hours is the delta between UTC and New York time zone so I strongly suspect some confusion related to the local vs. UTC setting.

Comment 1 Bill Nottingham 2011-06-02 15:31:56 UTC
Please attach:

/etc/adjtime

and the output of "find /etc/systemd/system /lib/systemd/system -name "*hwclock*"
"

Also, do you have initscripts-legacy installed?

Comment 2 Zach Tomkoski 2011-06-03 01:31:51 UTC
I have a Fedora 15 32 bit installation and have the same issue 

/etc/adjtime
-10463.504179 1307049660 0.000000
1307049660
LOCAL

output from find
/lib/systemd/system/hwclock-load.service
/lib/systemd/system/hwclock-save.service
/lib/systemd/system/shutdown.target.wants/hwclock-save.service

initscripts-legacy installed?
no

My system jumps on sleep also

Comment 3 chrobacilla 2011-06-03 09:19:21 UTC
I have a Fedora 15 32 bit installation upgraded from Fedora 14 
and have the same issue. I'm in +1 timezone and after boot I  get time shift
of +2 against time before boot (so 2 boots make 4 hours difference from bios 
time). 
It seems that running "hwclock --hctosys" (as mentioned in bug 584620)
after boot works until rebooted.

content of my /etc/adjtime 
12.989076 1307089805 0.000000
1307089805
LOCAL

/lib/systemd/system/shutdown.target.wants/hwclock-save.service
/lib/systemd/system/hwclock-save.service
/lib/systemd/system/hwclock-load.service

Comment 4 Jim 2011-06-05 01:12:32 UTC
I got similar output as Zach for all three questions. I assume you don't care about the first two lines of /etc/adjtime. Have not tried sleep.

Note: to get around the problem I have checked the "System clock uses UTC" box in Date/Time and that changed the third line of /etc/adjtime to "UTC". It shows time 4 hours in the past but it does not bounce around on reboot.

I have toggled the "System clock uses UTC" several times and /etc/adjtime is updated each time.

And, yes, I did look at /etc/adjtime prior to chaning the setting of "System clock uses UTC".

Comment 5 David A. De Graaf 2011-07-08 20:14:58 UTC
Me too.  I've verified on two system, both installed freshly, that system time is not adjusted for timezone during boot - until ntpd starts and fixes things.
I boot without rhgb, and with the equivalent of initlevel 3, so don't see time until long after ntpd has fixed local time.  However, timestamps in 
/var/log/messages clearly show that time was correct prior to the reboot, is displayed with a 4 hour increment starting at the boot, and goes back to correct local time when ntpd starts.  This is a "new feature" of Fedora 15.

Comment 6 Máximo Castañeda 2011-07-28 20:16:51 UTC
It also happened to me.  I found hwclock-save was enabled but hwclock-load wasn't.  Enabling hwclock-load solved the problem for me.  So here is how to test that:

$ systemctl --system is-enabled hwclock-load.service
$ echo $?
1
$ systemctl --system is-enabled hwclock-save.service
$ echo $?
0

0 meaning enabled and not 0 disabled.  Now enable hwclock-load:

# systemctl --system enable hwclock-load.service

$ systemctl --system is-enabled hwclock-load.service
$ echo $?
0

I don't know if that's The Right Way of doing things.  Also I don't know where the problem came from or when it started, but I had been using F15 (preupgraded from F14) without that problem for some time.

Comment 7 gregor 2011-09-07 19:56:29 UTC
(In reply to comment #4)
> I got similar output as Zach for all three questions. I assume you don't care
> about the first two lines of /etc/adjtime. Have not tried sleep.
> 
> Note: to get around the problem I have checked the "System clock uses UTC" box
> in Date/Time and that changed the third line of /etc/adjtime to "UTC". It shows
> time 4 hours in the past but it does not bounce around on reboot.
> 
> I have toggled the "System clock uses UTC" several times and /etc/adjtime is
> updated each time.
> 
> And, yes, I did look at /etc/adjtime prior to chaning the setting of "System
> clock uses UTC".

thx that solved my problem

greetings
gregor

Comment 8 Jim 2011-12-26 21:08:21 UTC
Just installed F16 via preupgrade and I am no longer seeing this problem. I have toggled "System Clock uses UTC" back on and local time is displayed correctly and there is no time change on reboot.

Jim


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