Bug#48866: Time-Zone still wrong
So if I understand you, the problem I ran into where my clock got reset is
to be expected from the way things work (assuming I made the change after
the initial configuration and reboot).
This behavior certainly took me by surprise, though it's not entirely clear
how to fix it. Your proposal
"I think it would be better to have the new setting to or not to use
"saving systemtime into CMOS clock on reboot/shutdown" function in
/etc/init.d/hwclock.sh, so users have choice of to use or not to use
it. If this can be done, then your case can be solved by editing
/etc/default/rcS to set "UTC=no" and (for example) "SaveSysTimeToCMOS=no"
or "SaveTime=no". This is just my thought."
would help, but I see some drawbacks. If the setting means never save the
time, then eventually someone will want to correct their clock for drift,
and be frustrated when the change doesn't stick between reboots.
If the setting means don't save the time immediately after the file is
changed, then the system has to figure out, as it shuts down, whether the
UTC setting was changed in the immediately preceding session. That might
require a little work. Also, it would mean you made a permanent entry (in
rcS) for a one-time event.
It seems to me a good behavior would be to reset the hardware clock whenever
someone resets the time, using whatever the current settings are. I don't
see a good reason to reset the hardware on every shutdown. Perhaps the
clock the CPU controls is more accurate? Or has better knowledge of things
like time-zones and daylight savings?
At any rate, this seems like more of a wishlist item (although from the
user's point of view it may seem more like a bug--but how many users change
the UTC setting after install?). So perhaps we should submit it to the
appropriate place (util-linux?). We could ask that one of these bugs be
reclassified to keep this trail for reference.
Reply to: