On Nov 10, 2011 2:44 PM, "David C. Rankin" <drankinatty@suddenlinkmail.com> 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??
Yeah I'm really not sure about the jump, ntp should be logging any changes anyway (though I believe it will not change the time if greater than some threshold) ... however, some time ago it was announced that localtime is no longer supported for a variety of well-known and good reasons. Windows just needs a small tweak (via registry IIRC) and it will behave. I would recommended switching to UTC hardware clock, and making said change. C Anthony [mobile]