|1 2 3 4 5 6 7 8 9|
There is no guarantee that your questions here will ever be answered. Readers at confidential sites must provide permission to publish. However, you can be published anonymously - just let us know!
Answered By Thomas Adam, Ben Okopnik, Mike Orr, Mike Ellis
I cant't seem to work this one out!!!! On my RedHat 6.1 Linux box, my system time is set to local time and hardware clock is set to UTC. These times appear to be OK.
[Ben] Why not set both to local time? This is one of the things that I idly fiddle with occasionally, and have not seen any bad effects from either method. Yes, the One True Unix Way is for the hardware clock to be set to UTC... but I don't pay it much mind, especially when it gets in my way. Besides, if you've got a dual-boot system, poor lil' Windows gets all confused about UTC anyway.
Whenever I save a file, then do an ls -l, the file time shows UTC.
Everything else, logs, etc. show local time. I am running ntpd, and this keeps the hardware clock OK.
[Ben] Just remember to run
once in a while. That way, after a couple of months, you can even turn off "ntpd" - and your system will keep perfect time (I think that a max deviation of one second in two or three months can be considered "perfect".) See the discussion in the "hwclock" manpage, and read about "/etc/adjtime".
I have a link from /etc/localtime to /usr/share/zoneinfo.
I have looked up numerous web sites about the clock system, but none have helped me. Any pointers in the right direction would be appreciated.
Thanks, Tony Ellem
Have you tried reading the clock-howto from the LDP <www.linuxdocs.org>???
What happens if you type in the following (as root):
[Ben] Baldur:~# hwclock -W unrecognized option `-W'
The short options for "hwclock" are "-[rwsavuD]", and the odd "-[AJSF]" for DEC Alphas. What is it that you were trying to do? "hwclock -D" (debug), maybe? I'm afraid that wouldn't be of much use: what the querent needs is a usage methodology rather than a fix for something that's broken.
[Chris G.] Hi Ben, This is not a challenge, but an observation that I have made. I used to set my real time clock to local time, but for some reason, the daylight savings time adjustment did not automatically occur.
I had to set my real time clock to UTC for things to work properly. I use the SuSE 6.4 distribution (2.2.14 kernel), and maybe there exists some sort of constraint with my distribution -- I don't know. Did you ever hear this crazy story before?
Regards, Chris Gianakopoulos
[Ben] Actually, I'm not sure by what mechanism that _is_ supposed to happen automatically - it never did for me whether I was using UTC or local. I just gave up and put it in 'cron'.
[Chris] Hmmm. That makes sense (the cron job).
[Mike Orr] It's supposed to be encoded in the timezone entry. It seems to be a hit or miss thing whether it actually adjusts on the right day-- sometimes it does, sometimes it doesn't.
BTW, daylight savings time does not apply to UTC. UTC is always sun time. But the Pacific time zone is always the same distance behind UK time, because UK time does move with daylight savings time.
When I was in Russia in 95 or 96, it was right when Russia was changing from the Soviet schedule for daylight savings to the western schedule. The Soviet schedule was a few weeks earlier, because it was early October when it happened.
Let's take a poll Monday and see how many clocks went back and how many didn't...
[Mike] My computer did all right.
[Faber] Interestingly, my main tower (running RH7.1) did, but my laptop (also running RH7.1) didn't. :-?
[Chris] OK, OK. My Linux system advanced to daylight savings time. However... first I thought it retarded back to nondaylight... but paying closer attention, I appeared to have advanced an additional hour. I'm trying another timezone setting (US/Central), and I'll see what happens next time.
P.S. My FreeBSD machine did work all right.
[Frank] As did my Mandrake 7.2 machine - with hardware clock set to UTC.
My other machine, running Mandrake 8.0 - with hardware clock set to local time - did not adjust though... Oh well, just meant I had to help the computer a bit...
[Ben] Mine was set to do it at midnight tonight; I've just set it back a day and did a manual adjustment. If it wasn't for youse guys, I wouldn't have had to do all that work... I'm suffering. No, really.
[Mike Ellis] Mine four did OK too...
RH7.1 24x7 RH7.1 dual-boot RH7.0 24x7 RH7.2 laptop
(my Solaris 8 box did OK as well, but somehow that seems less relevant...)
[Heather] We weren't paying close attention here to the Linux boxen, we have SuSE 7.1 and Debian, they all seemed fine. What we did notice is that the cable box and cellphone couldn't manage to agree, and I think the Token Windows Laptop flipped over early. Of course, we had to tweak the coffeepot on our own.
[Breen] My clock rolled forward correctly. A side effect was that a few jobs that run out of my crontab ran twice - I had them scheduled to run at 0100 on Sundays. I should probably change that before next October...
[Mike Ellis] I'd fix it by March, or they might not run at all!
P.S. 01:00 doesn't exist on March 31st 2002 as the clocks roll from 00:59:59 to 02:00:00 when "summer time" begins again - roll on March 31st!
[Breen] Erm -- right you are! Maybe I should just do it right now?
[Thomas] My clock is shafted. For some reason, my laptop thinks that it is 29 February 1909 !?! 1909 wasn't even a leap year!!
Don't you just love technology???
[Ben] Especially when it comes from... <cue the music>
<Rod Serling voice> The Twilight Zone. </RSv>
Is that what your 'top _switched_ to as a result of Daylight Wasting Time, or is that just what your date happens to be set to randomly? And what does your "hwclock" say? All sorts of odd things can happen with clock settings... pardon me, will happen with clock settings if "/etc/adjtime" is messed up. Read the "hwclock" man page (this usually leads, in one easy step, to deleting "/etc/adjtime" and re-running "hwclock --set ...", etc.)
[Thomas] I am always setting my hardware clock, thus:
(changing the appropriate values).
[Ben] Did you read up on the "--badyear" switch in "hwclock"?
Hmm. That might contribute to the problem. The only time you want to actually use "hwclock" to set the time is a) initially, and b) when you figure it's been long enough that the correction factor (1 second per <interval> is sufficiently exact for your purposes. The second time is also when you want to run "hwclock --adjust", right after you set it. The problem is that running "hwclock --set" twiddles "/etc/adjtime" - and all you really want in there is a correction factor for your drift rate. Otherwise, it's best to use "date -s" - I do it all the time, since I'm constantly shifting time zones; this does not mess with "/etc/adjtime".
In fact, here's a nifty little script that does this for me:
See attached zaptime.pl.txt
[Thomas] However the rate of drift on my laptop clock is enormous. I think my BIOS clock needs fixing. The poor things been living in Victorian times for the last year now.....
[Ben] The usual reason for the drift rate zooming out of sight is a CMOS battery that's going bad. I've probably seen that happen two dozen times or more over the years.
|1 2 3 4 5 6 7 8 9|