PDA

View Full Version : Fedora 9 setting clock back 4 hours on each reboot



jim1944
2nd June 2008, 04:33 AM
Each time I boot F9 on my i586, the clock is set back 4 hours. Example: date command shows 18:00 EDT. I reboot and go into BIOS setup and note that the clock is a little after 18:00. But when F9 comes up, date command shows a little after 14:00 EDT.

This does not happen when I boot the i686 live CD on my other machine. This did not happen with F8 or F7.

Any ideas what is going on?

Thanks
Jim

SlowJet
2nd June 2008, 05:25 AM
That is happening on many recent Linux systems.
The date, time, zone, city , blah, blah, b;ah has become a set of ridicules glitz and bling that serves no purpose.
A simple What is your time zone? question that goes back to the install server or some other time server to set the time is all that is needed. KDE4 has 3 different clocks. There is 3 ways to set the main daetime clock, and none of they work, or will not update the real clock (even with auth set). And then there is ut, which does not show up on most screens after the initial install.

R-I-D-I-C-U-L-E-S to the edge of insanity.

SJ

notageek
2nd June 2008, 05:27 AM
Try the following


hwclock --localtime --systohc

And make sure that UTC is unchecked in this command


timeconfig

SlowJet
2nd June 2008, 05:49 AM
Thanks for the commands.
It's all coming back to me,now.
I sort of remember telling the kids, be sure to set your hwclocks back or you'll be late for school. :)

I thot time was set but it is configured? Makes no since.

SJ

SlowJet
2nd June 2008, 06:23 AM
man hwclock

hwclock --set --date '06/01/2008 10:21:15' --localtime
hwclock --show
hwclock --hctosys

So why can't all those gui do that?

SJ

stevea
2nd June 2008, 06:47 AM
That is happening on many recent Linux systems.
The date, time, zone, city , blah, blah, b;ah has become a set of ridicules glitz and bling that serves no purpose.
A simple What is your time zone? question that goes back to the install server or some other time server to set the time is all that is needed. KDE4 has 3 different clocks. There is 3 ways to set the main daetime clock, and none of they work, or will not update the real clock (even with auth set). And then there is ut, which does not show up on most screens after the initial install.

R-I-D-I-C-U-L-E-S to the edge of insanity.

SJ


Really ? Is that really the problem ?

Linux has several notions of time. The most basic and only on accessible from boot is the ancient PC architecture RTC clock. This clock is NOT architecture independent so it has to go into the linux-2.6.xx/arch directory only for PCs - the kernel cannot depend on since it's for PCs only - so there is no system call for setting the RTC. Linux is not written only for PCs. Apps like hwclock (PC only too) have to open a device driver /dev/rtc and manipulate the registers. You write a tv or timeval to the device (on a PC) and it sets the RTC - but the timing is not get good - could be off by milliseconds. Anyway the RTC clock is completely inadequate for normal system use - the resolution is only 1 second and most runs off a cheap crystal oscillator that was originally designed for TV use. So typical PC architecture systems get the RTC time at bootup and set the software clock.

The software clock SWC ((used to - I think it still does) gets a 1/second interrupt but it also uses the CPU cycle register or other similar source of a high-res timer to calculate the intersecond intervals ... typically to nanoseconds these days. Anyway the gettimeofday() syscall gets called a shocking number of times so the implementation has to be cheap and efficient. Oh yeah the ability to get the correct intersecond time on an SMP model PC is not a trivial problem.

Of course a SW clock that starts from the not-so-great RTC can never be very accurate. To do better we typically use ntp protocol - which is one of the most complex convoluted network protocols around. You don't just get time from across the net, you have to test the network transit time (which may not be symmetric) and then you get a feed from (minimum 3 IIRC) servers and these all have to sync "well enough" before it starts syncing the SW clock, but then it also calculates a drift figure to correct your SWC between ntp updates. So actually the ntp keeps it's own notion of time and only updates the SWC when certain quality issues have been meet. As an aside you can make your system into a strata1 ntp server with a $80 GPS and a major kernel patch - you have to route the highly accurate 1pps GPS line to a interrupt line on your system (often a serial line).
--

So normal apps and nearly anything that is part of Gnome or KDE for example may set the SW clock but they won't set the RTC b/c these packages must run on non-PCs. Frankly I don't care how many clock utilities exist on the desktop - used one and remove the rest. Only a few apps change the RTC clock.
==

Most probably the current problem is caused by dual booting Windows. Win only supports having the RTC set to local time, and Linux default and prefers to have the RTC in UTC time. UTC really makes more sense. As the kernel/time.c files says:

/*
* Adjust the time obtained from the CMOS to be UTC time instead of
* local time.
*
* This is ugly, but preferable to the alternatives. Otherwise we
* would either need to write a program to do it in /etc/rc (and risk
* confusion if the program gets run more than once; it would also be
* hard to make the program warp the clock precisely n hours) or
* compile in the timezone information into the kernel. Bad, bad....
*
* - TYT, 1992-01-01
*
* The best thing to do is to keep the CMOS clock in universal time (UTC)
* as real UNIX machines always do it. This avoids all headaches about
* daylight saving times and warping kernel clocks.
*/

SlowJet
2nd June 2008, 07:32 AM
Yes, really. I understand what your are addressing but that is not the part the user is seeing.

The install instructions say use localtime if you have windows or your compters clock automatically adjusts for daylightsavingtime.

So you click or un-click ut box.

Next, say you what to adjust the time. It doesn't get saved.

Say you made an AM PM error for 12 hour time. The adjustment doesn't get saved.

Say you are fed up with DLSt or are rebeling against the gov for going Double-DLST or changing it 2 weeks earlier,
and you want to set to ut time. There is no check box.

Now for the bottom line.
You install and set everything perfect and the time is off 4 hours.
you are at ut-7 on DLST, normally ut-8 on ST.

This error has nothing to do with datetime or clocks. It is just bad programming and lake of the simplest Q/A testing. period. Simply rebooting twice would have caught the error before anything ever left the factory.

SJ

stevea
2nd June 2008, 02:43 PM
Yes, really. I understand what your are addressing but that is not the part the user is seeing.

It's necessary for the user to understand that the desktop utils typically only adjust the SW Clock.


The install instructions say use localtime if you have windows or your compters clock automatically adjusts for daylightsavingtime.

So you click or un-click ut box.

Next, say you what to adjust the time. It doesn't get saved.

If some particular installer doesn't set the RTC - then that's an installer bug. But otherwise this is normal for desktop utils as I said. No surprise there.. AFAIK the ONLY place where the kernel proper sets RTC time is in the ntp kernel code - if the ntp notion of time is sync'ed then it calls some "set persisitent_time()" architecturally specific routine once in a long while. So your only options to set the RTC clock are to use the BIOS, use hwclock or other architecture specific programs like hwclock, or run ntp.

BTW there is a more generic /dev/rtc interface that runs on some other architectures that use a similar clock chips., but many embedded Linux systems have no RTC at all. The set_persistent_time rtn is ifdef'ed or just a stub then and ntp of course can't set anything permanent.



Say you made an AM PM error for 12 hour time. The adjustment doesn't get saved.

It certainly does if you use one of the methods mentioned - like hwclock - to do it. *BUT* you must also be aware that the very first settimeofday system call the kernel sees is used to set the "warp clock" offset and it's never changed after than AFAIK (see man settimeofday). So you can change the RTC TZ field all day and it prolly has no impact on the kernel offset until you reboot. That's somewhat a guess, as I have seen the settimeofday kernel code but I haven't checked the /dev/rtc driver. That a limitation of warp clock - which is a complete hack to begin with.


Say you are fed up with DLSt or are rebeling against the gov for going Double-DLST or changing it 2 weeks earlier,
and you want to set to ut time. There is no check box.

The Linux kernel and BSD kernels were all written to use UTC in the RTC. As the kernel comment I posted notes the "warp clock" routines (kernel routines to allow use of a localtime-RTC) are a hack and ugly. Think about it - should the kernel really be responsible for changing time_warp every time the US Congress starts demagoguing abt energy and changing DST ? No that should be a userspace issue.

*IF* you set your RTC to UTC, then you can set your userspace TZ (and DST) to anything you want in locale and everything "just works". Each user can have their own TZ for that matter and you can screw with it as you please. Each app can have it's own as well. There are library routines (libc) that actually calculate the DST warp (including all date, not just the current decade) and I assure you they aren't pretty.

The problem is that Windows (not sure abt Vista) insists on localtime-RTC and setting Windows time (note Win is PC-only) bangs on the RTC every time you set time.


Now for the bottom line.
You install and set everything perfect and the time is off 4 hours.
you are at ut-7 on DLST, normally ut-8 on ST.

This error has nothing to do with datetime or clocks. It is just bad programming and lake of the simplest Q/A testing. period. Simply rebooting twice would have caught the error before anything ever left the factory.

SJ

I haven't seen the specific error and it's not entirely clear from your comment what the source is. It *sounds* like you are trying to make the kernel use warp clock (generally a bad idea) and you are unhappy b/c the kernel wasn't built to recognize changes to warp clock TZ values after the first setttimeofday call.

The correct solution is to always use UTC-RTC ((and dump Windows, or at least run it in a VM)). In case I haven't made it clear, running localtime-RTC is a hack, and it causes repercussions that aren't pretty. You can only have one kernel with one warp-clock TZ and that's not flexible. In userspace you have a default TZ from /etc/localtime and each user or even each app can set it's own TZ+DST (and ignore /etc/localtime). I have no idea what the several KDE clocks do, but they may each squirrel away their own notion of TZ. There is fundamentally no reason why the several clocks have to display the same TZ+DST time.

FWIW the "UTC" flag from the installer on Fedora only create a file:line like
/etc/sysconfig/clock:UTC=true
and this is used in the /etc/rc.d/rc.sysinit script to make that very first settimeofday call and this to set the kernel swark-clock.
===


I empathize with your complaint SJ, but I don't agree that based on the description it's an error unless the installer really fails to set RTC. The clock schema is necessarily complex, and a good bit of complexity already is added to accommodate an outdated and silly Windows convention of using localtime-RTC. The solution is not to switch to the Windows convention. If ppl want to dual-boot Win and use localtime-RTC then they may have to reboot to see the TZ changes take effect. Hopefully the small population of localtime-RTC users don't change TZ often enough to care much.

jim1944
3rd June 2008, 12:10 AM
I'll repeat what the error I reported is because some seem to have missed it:
1. Date command says it is 1800 EDT.
2. I reboot and go into BIOS setup and the clock (I'm guessing that's the RTC clock) says it is 1800. It doesn't say what time zone it is.
3. I exit BIOS setup without making any changes and after reboot completes, date command says it is 1400 EDT.
4. I reboot and go into BIOS setup and the clock says it is 1400.
5. I exit BIOS setup without making any changes and after reboot completes, date command says it is 1000 EDT.

This is a dual boot machine but I haven't booted Windows in months.

I'll try the things notageek suggests but, IMO, these are workarounds to a software bug. There is no way that this behavior makes any rational sense.

Jim

jim1944
3rd June 2008, 02:42 AM
Try the following


hwclock --localtime --systohc

And make sure that UTC is unchecked in this command


timeconfig
hwclock didn't do anything and my installation does not have timeconfig.

However I was able to solve the problem: I went into the Data & Time gui and checked (not unchecked) the "System clock uses UTC" option. Now the HW clock is on UTC time, date command shows EDT time and time is not set at reboots.

It appears that with my rather old computer (its an i586 with BIOS date 1997), F9's clock management is broken if the system clock does not use UTC. As I said, this problem does not occur with the live CD on my newer machines.

Thanks
Jim

notageek
3rd June 2008, 04:54 AM
Hmm... thats interesting, its exactly the opposite of what I tried.

The problem on my box (on F9) was that the clock was being set back 5.5 hrs (which is GMT), I found out that my HW clock was set to UTC, so I changed back and then reset the HW clock.

My observation was contrary to your's, I found incorrect time with system clock set to UTC.

Although those were the exact commands I tried to fix this on my box.

Glad that you got it working.

I don't recall if I had to change time after running hwclock command, but the time remained consistent across reboot on multiple OS.

stevea
3rd June 2008, 07:41 AM
I'll repeat what the error I reported is because some seem to have missed it:
1. Date command says it is 1800 EDT.
2. I reboot and go into BIOS setup and the clock (I'm guessing that's the RTC clock) says it is 1800. It doesn't say what time zone it is.
3. I exit BIOS setup without making any changes and after reboot completes, date command says it is 1400 EDT.
4. I reboot and go into BIOS setup and the clock says it is 1400.
5. I exit BIOS setup without making any changes and after reboot completes, date command says it is 1000 EDT.

This is a dual boot machine but I haven't booted Windows in months.

I'll try the things notageek suggests but, IMO, these are workarounds to a software bug. There is no way that this behavior makes any rational sense.

Jim

Thanks for the concise restatement. I installed F9 with a non-UTC RTC clock for the purpose of trying to reproduce your problem.

Before installation I set the RTC to my local time (UTC-4) and then installed minimal F9 and told the installer that I was in LosAngeles ,PDT (I think that's UTC-7 at the moment). After the reboot and initial setup I got to a terminal and was (after a little fussing around) stunned to see that the "date" command reported time as "EDT" !!! That's crazy. I never indicated EDT - just the opposite I told the installer PST and there was no network access or ntp to correct it.

The numerical time from "date" matched RTC and this makes sense since I said the RTC was in local time. It *should* be performing the kernel time warp, (so the SW clok is UTC) and then the gettimeofday() result is converted to local time (unwarped by ctime and other glibc routines.

The very funny thing is that when I set the timezone to PST this had no impact. I had to set the timezome to Midway and back to LosAngelese and then this had a 3hr impact on the reported time from "date". This can be explained b/c the original time was set EST and eventually movd by 3hrs to LosAngeles time.

The entire userspace time control has changed in F9, but I can't find any clear errors. I believe the problem is in the installer.

On F9 ... the rc.sysinit no longer calls hwclock to set the kernel time warp. Instead the udev rules for the /dev/rtc device have this text:
/etc/udev/rules.d/88-clock.rules:ACTION=="add", SUBSYSTEM=="rtc", RUN+="/sbin/hwclock --hctosys --rtc=/dev/%k"
/etc/udev/rules.d/88-clock.rules:ACTION=="add", MAJOR==10, MINOR==135, RUN+="/sbin/hwclock --hctosys --rtc=/dev/%k"

So it *appears* that creating the /dev/rtc via udevd causes the kernel warp to be set.
Idon't know where/how the installer sets /etc/localtime but I suspect that's the problem.

I'd really like to look into this further but - out of time (sic).
--

The suscint conclusion:
1/ Set the RTC to UTC !
2/ Use ntp.

Divit11
4th June 2008, 04:46 AM
I was following this thread because like Jim1944 I also have a dual boot machine with XP Home SP3 and FC9. I could not correct the time using the GUI interface but followed these steps to correct my clock.
1 - Terminal (as root) timeconfig and unchecked the UTC box and made sure I was on Chicago time
2 - Rebooted into MS XP and found my time was wrong! Used the internet time set program to get my local time reset.
3 - Rebooted into FC9 and the time and map were now showing my correct local time.

Hope this helps.
D

jim1944
12th June 2008, 09:29 PM
Hmm... thats interesting, its exactly the opposite of what I tried.

The problem on my box (on F9) was that the clock was being set back 5.5 hrs (which is GMT), I found out that my HW clock was set to UTC, so I changed back and then reset the HW clock.

My observation was contrary to your's, I found incorrect time with system clock set to UTC.

Although those were the exact commands I tried to fix this on my box.

Glad that you got it working.

I don't recall if I had to change time after running hwclock command, but the time remained consistent across reboot on multiple OS.
This bug seems to match my experience: https://bugzilla.redhat.com/show_bug.cgi?id=447019

notageek
13th June 2008, 04:25 AM
Hmm... an exact opposite of my experience, I was able to fix this by the steps I outlined earlier, maybe there are two bugs! :confused: