On Nov 10, 2011 2:44 PM, "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx> 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]
