On Sat, 7 Apr 2012, Paul Donohue wrote:
I've not much experience with resetting the system clock (I always use UTC
for system clock), but this sounds like it might be related to the /etc/adjtime
feature of hwclock. This is supposed to compensate for a linear systematic
drift in the time kept by the hardware clock.
According to man page for hwclock, the drift calculations get computed anew
everytime hwclock called with --set or --systohc options, which I believe
in most setups is done when machine is shutdown. I believe this process looks
at how much drift between hw clock and system clock occured while system is
on.
If you abruptly add/lose an hour on the hw clock, and did not inhibit the
/etc/adjtime settings, you will likely cause an unreasonably large systematic
drift to get recorded in adjtime afterwards, gradually diminishing as the
more reasonable drifts between system and hw clocks while system is on get
merged into this value. I expect that would manifest itself as
some odd changes in the time in reboots shortly following the daylight saving's
changes and diminishing over time.
My recommendations would be:
1) keep hw clock in UTC, although I understand potential reluctance due to
other OSes that remain nameless which stupidly expect a hw clock running in
local timezone.
2) Use --noadjfile option to hwclock when changing time due to daylight savings
changes.
