Seem to be some confusion here.
I think electroman00 is pointing out the correct way to set the time zone before you turn on NTP. He is quoting from the manual.
It's in the manual but not in the wiki, which could lend itself to this type of issue expressed by the OP.
You have hit on an interesting hardware/software time relationship that just has not come up before because "nobody??" else is using the bios settings to reboot their server.
Rebooting is irrelevant to the issue here, correcting the date/time configuration solves the issue here and OP can reboot every minute if he wants.
Although it may not be wise to reboot every minute or every day for that matter, to each his own.
If I understand correctly from the posts above, the system clock should be set to UTC/GMT which is PST/Los Angeles +8hrs. (the correct way to say this is that PST = UTC -8).
The system clock will always be set to UTC and a software +/- offset based on your time zone to display to the user, the system clock is always maintained UTC on virtually all computer systems, thus the term
Coordinated Universal Time UTC.
This means that any Bios reboots will have to be calculated by taking the local time you want the system to reboot +8.
When the time is updated the bios (hardware clock) will be updated to your time zone, not UTC, the bios clock knows nothing of time zones, never has and never will, it's superfluous code that isn't needed in the bios.
Most all time sync software will update the OS system clock (software clock) to UTC and the bios (hardware clock) to your time zone, sometimes the bios update is optional/configurable.
All NTP servers are UTC, thus your OS system clock (software clock) is updated to UTC as Charlie stated, then any software that displays the time must know the time zone your in to display it correctly.
Thus....
OS system clock (software clock) updated to UTC
and
Bios (hardware clock) updated to your time zone via the +/- TZ offset
To test the bios clock is updated, simply set the bios time incorrectly and run any time sync software, recheck the bios clock.
When you manually enter the bios time you should enter your time zone time, not UTC time.But you really don't have to set it if your using a good time sync app.
As you understand, you do not set which timezone the system is in on the hardware clock. Instead you set the hardware clock to the current UTC/GMT time.
First read...
http://en.wikipedia.org/wiki/Coordinated_Universal_TimeIncorrect....you set bios clock (hardware) to your time zone, since the bios doesn't know about TZ's and cannot adjust for them.
In fact you don't have to set the bios (hardware) clock, it will be updated by NTP service and set to your
time zone via the closest UTC time server you choose, which may then be reported/displayed via some software app to the user as UTC adjusted for the user Time Zone.
Setting and Reading the OS system software clock are two different methods, always referenced to UTC.
When you then set the timezone in SME, on bootup SME calculates the difference from UTC and sets the SOFTWARE clock to the correct LOCAL time. (in this case PST)
OS system clock is always UTC and software app adjusted for time zone for display.
If it doesn't then there is likely a bug, hardware or software or last but not least a incorrect configuration, which is what we have here in the thread.
Computer systems don't care what time zone their in, so all time sensitive systems are synced to UTC so no time zone adjustment needs to be done to maintain/improve accuracy.
If systems needed to TZ calc then the time it takes to calc would need to be employed in the final time calc as a correction and each system runs at different speeds so their corrections would be different adding to inaccuracy.
Humans do care what time zone their in, so systems will usually always adjust for TZ via software, no big deal if it's off by a few milliseconds.
The entire GPS system for example uses UTC, synced from Atomic Clocks and corrected for many issues that occur within the system.
One example of a correction is the time it takes for the radio signal to travel 12,500 miles from earth to the satellite.
A millisecond error in the GPS world is thousands of feet of error in the final position calc.
The GPS system is time accuracy and measurement to the MAX and simple geometry.
Fortunately we don't have to get involved with such time accuracy with our systems.
Since most were asleep in geometry, we don't have to worry about that either, simply buy a GSP and you might know where you are.
Or for that matter where your going.
Go here
http://www.n2yo.com/?k=20 and select a GPS satellite, make note of the altitude and speed and try to imagine the time accuracy you need to calc a 3 axis position within a few feet from 12,500 miles away.
Yup....you also get altitude above MSL (mean sea level).
Why is it only
above MSL and not
below MSL, radio signals do not traverse water (H2O).
So GPS is no help to a submerged submarine, they have to nav the old fashioned way, when submerged.
Thus a basic example for the use of UTC and the level of accuracy that may be needed within a system.
OK. As far as I am concerned, no other discussion is necessary. Until some new demand or observation be made regarding my system by me that comes up against the system clock, Problem Solved.
If it works for you it works for me, however
it is the solution to your problem and misunderstanding.
And your welcome anyway, even if it won't help you, it may help others.
hth
28 Replies
3386 Views