Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As I had tested, there are situation that zdump show the correct info, but a Perl script testing fail. Our production server does not allow us to do the real rollover test. I thought the Perl script is a good simulation. Wonder why.....
Found that in all old Linux machines, strftime(%Z) *never* return the daylight saving timezone (eg never EDT), always the "standard" timezone only (EST)!
I just checked my Armada running 2.6.7 (debian Distro) and lo! it is correct.. At the beginning of Feb, I used synaptic to install elinks, and it must have also installed all the new time zone stuff...
guys, brydons method works (when you swap the two destinations in the ln command)
It's really weird though. Everything looks right. I changed the time to 1:59am on march 11 and it hit 3:00 like it should. When I rebooted the machine and when it started up I see it saying "setting clock 3:00" but when it full boots up, the clock read 10:00PM March 10 (5 hours behind).
Use the hwclock command to see current time on the hardware clock. Use date to system current time on the system clock. Once you are sure the system clock is correct use the hwclock -systohc to set your hardware clock to your system time.
I'd do another reboot after that just to be sure everything was OK.
P.S. I have seen some installs ask whether the hardware clock uses UTC (it should). If you had this NOT using UTC but the system time using UTC (as it should) then you'd be exactly 5 hours off in the U.S. Eastern time zone. Hopefully what I wrote above will solve it if you had answered this differently during the original install - I don't know of any other config that would save that difference but can see that there might be one.
Last edited by MensaWater; 02-23-2007 at 08:57 AM.
Use the hwclock command to see current time on the hardware clock. Use date to system current time on the system clock. Once you are sure the system clock is correct use the hwclock -systohc to set your hardware clock to your system time.
I'd do another reboot after that just to be sure everything was OK.
P.S. I have seen some installs ask whether the hardware clock uses UTC (it should). If you had this NOT using UTC but the system time using UTC (as it should) then you'd be exactly 5 hours off in the U.S. Eastern time zone. Hopefully what I wrote above will solve it if you had answered this differently during the original install - I don't know of any other config that would save that difference but can see that there might be one.
your the man, you were absoultely right. The system had UTC disabled by default. As soon as I enabled it and rebooted, it resolved my issue.
I have a quick question though. Should UTC be disabled or enabled? What does it do and what are it's advantages/disadvantages?
Also, does the hardware clock always use UTC? which command can tell me if the hardware clock is using utc? the hwclock just tells me the time and the time zone (EST)
hardware clocks so far as I know don't care about time zones though it sounds as if your bios had a setting for it. So given a choice for UTC enabled/disabled in BIOS I'd probably enable it.
Linux/UNIX want the underlying system time to be UTC. They use timezone (TZ) simply to determine how to display it to you. Based on this you should use UTC for hardware clock (if setting outside the OS e.g. in the BIOS setup screen). Within the OS as mentioned this is done transparently.
Also as noted you can use the hwclock command in Linux to deal with the hardware clock including:
1) Setting the hardware clock to same time as the system clock
2) Setting system clock to the same time as the hardware clock
3) Seeing what the current time is on the hardware clock.
(man hwclock)
Typically I setup NTP to insure the System Clock is right. I then do option 1 above to insure the hardware clock has the same time as system time which is what NTP updates. (man ntpd, man ntpd.conf).
Typing "date;hwclock" will show you the system time (date) and the hardware clock (hwclock) at nearly the same time so you can verify they are the same.
hardware clocks so far as I know don't care about time zones though it sounds as if your bios had a setting for it. So given a choice for UTC enabled/disabled in BIOS I'd probably enable it.
Linux/UNIX want the underlying system time to be UTC. They use timezone (TZ) simply to determine how to display it to you. Based on this you should use UTC for hardware clock (if setting outside the OS e.g. in the BIOS setup screen). Within the OS as mentioned this is done transparently.
Also as noted you can use the hwclock command in Linux to deal with the hardware clock including:
1) Setting the hardware clock to same time as the system clock
2) Setting system clock to the same time as the hardware clock
3) Seeing what the current time is on the hardware clock.
(man hwclock)
Typically I setup NTP to insure the System Clock is right. I then do option 1 above to insure the hardware clock has the same time as system time which is what NTP updates. (man ntpd, man ntpd.conf).
Typing "date;hwclock" will show you the system time (date) and the hardware clock (hwclock) at nearly the same time so you can verify they are the same.
Thanks a lot for the response and help.
One more quick question: Is there a way I can determine if the system and hardware clock has UTC enabled from the command prompt? Also, can we enable/disable utc for the system/hardware from the command prompt? if so how can that be done?
UTC (Universal Time) = GMT (Greenwich Mean Time) = Zulu
Note: In the UK they use GMT part of the year then go to British Summer Time (at least in locations I previously interacted with). This means that the time in the UK is not always GMT so don't base your assumption about UTC based on, say, London's current time. Restated: UTC does equal GMT but does NOT always equal "the current time in the UK".
I don't know of a way to set BIOS (on x86 systems) from the command prompt. Not saying there isn't one. They would be hardware specific and in the BIOS so typically are set before the OS is booted. It may be possible to READ the values using snmp but that would depend on the MIB for your specific system. I'm not an snmp expert so can only give you that as a hint for where to research.
As mentioned the hwclock command however will show you the hardware clock time and allow you to set the hardware clock time. If you look at "man hwclock" it will give you usage for the command. I note it does have an option "--utc".
Last edited by MensaWater; 02-27-2007 at 01:24 PM.
UTC (Universal Time) = GMT (Greenwich Mean Time) = Zulu
Note: In the UK they use GMT part of the year then go to British Summer Time (at least in locations I previously interacted with). This means that the time in the UK is not always GMT so don't base your assumption about UTC based on, say, London's current time. Restated: UTC does equal GMT but does NOT always equal "the current time in the UK".
I don't know of a way to set BIOS (on x86 systems) from the command prompt. Not saying there isn't one. They would be hardware specific and in the BIOS so typically are set before the OS is booted. It may be possible to READ the values using snmp but that would depend on the MIB for your specific system. I'm not an snmp expert so can only give you that as a hint for where to research.
As mentioned the hwclock command however will show you the hardware clock time and allow you to set the hardware clock time. If you look at "man hwclock" it will give you usage for the command. I note it does have an option "--utc".
ok, I see what your saying.
I have another box here. If I issue the hwclock command it displays 4:17.
If I issue the hwclock --utc command, it shows 11:18.
If I issue the clock command, I got 4:17.
So does that mean that utc is disabled on the hardware clock? I'm assuming that it does...
I don't think so. It appears from your result that the --utc is just showing you what the real UTC time is (presumably based on whatever your timezone is) to the real time on the lock. Even though it is the "hwclock" command it is running in the "system" where you have your timezone set.
As I noted I would simply set the system time (using the date command) then use the hwclock -systohc to update the hardware clock with the system time. It is system time that you are most interested in from the OS perspective.
The final test is still valid and will return Apr 1 if the timezone does not work well, and Mar 1 if it does.
# zdump -v /etc/localtime | grep 2007
Quote:
Originally Posted by Brydon
Let's see if I can make this a little simple. I have just finished updating my Red Hat 9 servers, Fedora 6 notebook and all my Windoze machines.
Let's start off by clearing up some misconceptions. NTP only sets the UTC time on the computer, the timezone files will display this time in the correct time zone for your region.
Newer, supported distros will have glibc updates ready for the timezone change. Un-supported distros as in Red Hat 9 need a little work.
On my servers, I used
#zdump -v /etc/localtime | grep 2007
to verify the 2007 timezone settings. Mine showed April 1st as the date of change... and not March 11.
to compile the timezone data files. I then copied the EST5EDT file to /usr/share/zoneinfo/ directory and America/Montreal file into /usr/share/zoneinfo/America directory. Doing a quick test will make sure these new files are good.
/etc/localtime Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
Hope this helped.
BTW, If you want to update Windoze,I used tzedit.exe to get this to work.
The link flip has already been pointed out. It might be good to review an entire thread to prevent duplication of information. (Especially long ones like this.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
debian looks after me
