Results 1 to 10 of 11
The clock keeps changing back to UTC which is not so good. My local timezone is about UTC +7. It appears to be good until I reboot. I can change ...
- 02-24-2011 #1Just Joined!
- Join Date
- Apr 2007
- Posts
- 66
hw clock drift
The clock keeps changing back to UTC which is not so good. My local timezone is about UTC +7. It appears to be good until I reboot. I can change manually in the bios or enter the following command
hwclock --systohc --localtime
No matter what it goes back to UTC. I checked the timezone data is correctly recorded and it is...
The command hwclock returns
Wed 23 Feb 2011 08:18:05 PM ICT
The command date returns
Wed Feb 23 20:19:25 ICT 2011
so this shows the system time and the hardware time are the same but they use the 12 and 24 hour clock which is strange since the bios supports only the 24 hour clock. I wonder if the time / date syntax has to be presented in the same way on both the system and the hardware? The time ICT zone appears to be correct.
Anything strike you as odd?
- 02-24-2011 #2Just Joined!
- Join Date
- Mar 2010
- Posts
- 79
ntp usually solves time issues for me.
I can't promise it will work in your case, but you can try
(usually i only need to install it):
NTP - Debian Wiki
- 02-25-2011 #3
The time is the time, but it can be displayed in various ways. Changing the display from 12-hour to 24-hour format doesn't affect the time at all, just the way it's shown on the screen. Linux uses UTC by default, and changes the display to show the local time by checking the time zone settings. If you use ntp or ntpdate to set the time, and give the system your time zone, you should have no further problems.
- 02-25-2011 #4Just Joined!
- Join Date
- Apr 2007
- Posts
- 66
something is not right ... sadly.
I have ntp installed, even using an ntp server from the same time zone.
The problem is that if I power the system down I have the bios set to bring it up at a later time. It never does. Well it does but it is always 7 hours late. If I then look at the hw clock as maintained by the bios it has always changed to run 7 hours earlier which explains why it is late in starting.
I can see from the system logs that the system and the ntp server communicate as part of the start up process.
What I do not understand is why the hw clock is changing time zone.
- 02-25-2011 #5
It's a problem with your settings, somewhere. The system clock should always be set to UTC. What your BIOS does, I don't know, because there are a number of those around. You may need to do some research on your BIOS and how it works.
- 02-26-2011 #6Just Joined!
- Join Date
- Apr 2007
- Posts
- 66
trouble is that Bios manufacturers do not exactly fall over themselves publishing any information ... I am running AMI ver. 08.00.14 of 11/3/10.You may need to do some research on your BIOS and how it works.
However, I feel it hard to blame the bios at all since that does not make reference to an external clock ... it simply maintains the time that it has been given. But the bios time keeps changing (by exactly 7 hours).
The time should be the same as system time. You suggest that there is a problem with the settings. Fine, I have no issue with that but do you have any suggestion with what that could be?
The command
hwclock --systohc --localtime
should sync both hardware time and localtime (which is system time) and by looking at both (with date and hwclock) they do appear to be correct but when the system powers down something happens and changes the hardware time. That is what I cannot figure out ....
- 02-26-2011 #7
No, that command sets the system time to local time, not UTC. When the PC is powered up, the BIOS assumes the time it's keeping is UTC, and your time is off. You should be using --utc, not --localtime, IMO. The hardware clock should be kept in UTC, and so should the system time, and the display can be in whatever time zone you want.
Using hwclock is not necessary at all if you use ntp, and I think you may be unnecessarily confusing your PC.
- 02-27-2011 #8Just Joined!
- Join Date
- Apr 2007
- Posts
- 66
so please consider this ........
never mind the hardware clock. Forget it.
Think about the system clock. The system clock is set to local time. It keeps time. It is correct and on boot up I can see ntp communicate and verify the time.
I then set a cron event. I set cron to use local time. That is reasonable. When the event time appears nothing happens. If I wait for 7 hours more the event runs. That is the hw time.
This does not make any sense at all. Cron should run off the system time should it not? Or am I misunderstanding something fundamental?
- 02-27-2011 #9
System time should NEVER be set to local time. It should ALWAYS be set to UTC. Setting the system time to local time is the cause of all your problems. You have already told the system that your local time zone is 7 hours ahead of UTC, and that's all it needs to know. When you put a time into cron, it assumes you're using local time, and converts that to UTC.
- 03-06-2011 #10Just Joined!
- Join Date
- Apr 2007
- Posts
- 66
hmmm well there is a slight problem .... the hardware clock seems firmly stuck in ICT.
If I issue the command hwclock it shows the hw time which is the same as local time and it is also identified as ICT.
I then issue a command hwclock --systohc --utc but the time does not change to utc it stays identified as ICT. I have also tried with hwclock --set --u and hwclock --set --utc but there is also no change.
Perhaps I do not understand what is time. The hwclock to my understanding is the time maintained by the Bios. The system time is the time maintained by the operating system. What I do not quite appreciate is why system time should never be anything other than utc, to me that does not make any sense at all. I am not in utc .... I am utc +7 which is ICT. Similarly ... if system time is utc it will be 7 hours behind so instead of displaying local time of 17:00 it will show that the time is 10:00. That is quite important when it comes to running cron....


Reply With Quote
