On 10-11-2011 20:44, David C. Rankin wrote:
On 11/10/2011 01:55 PM, Mauro Santos wrote:
On 10-11-2011 19:16, David C. Rankin wrote:
Richard, David - check your hardware clock "# hwclock -r" and compare
that to the time returned by "# date". If they are hours apart, then
make sure your sysclock is correct and set the hardware clock to your
sysclock with "# hwclock -w". Worth checking regardless. I know this
used to be done on boot or shutdown and I don't know why it isn't
anymore. I'll do some more digging.
You should take into account that 'hwclock -r' and 'date' might return
different
times and things will still be ok, it all depends on if you have the
clock set
to UTC or localtime and your timezone. The man page says there is some
autodetection logic but as with all things it can fail.
True, hwclock always returns time in 'localtime' as does 'date'. Both
also provide the '-u' option to return UTC. This box has the hwclock set
to localtime because it dual-boots with M$. Come to think about it, it
is one of my only boxes that is dual-boot. I wonder if the rtc set to
localtime may be uncovering a regression that is causing this strange
behavior, because honestly I can't explain jumping backwards in time
over 13.75 hours with ntp running??
I thought hwclock would return the time set in the CMOS clock, which
should be set to UTC (if you set HARDWARECLOCK="UTC" in /etc/rc.conf)
and date would return localtime due to taking the timezone setting into
account. That is why I said they could be different but maybe I'm
looking at it in the wrong way. If everything is set to localtime then
both hwclock and date should return the same time.
--
Mauro Santos
