Bug#48866: Time-Zone still wrong
I just found that why "--localtime" is required to solve
the case in #53808.
I wrote:
| 1) At the initial install stage, boot-floppies set UTC=yes or UTC=no
| in /etc/default/rcS in the target (intalled) partition. At this time,
| boot-floppies does not use "hwclock" command (there is no "*clock"
| command in boot-floppies), so /etc/adjtime is not created in target partition.
|
| 2) After the first reboot, the installed system boot up from the hard disk,
| and /etc/init.d/hwclock.sh does set the system clock under the setting
| in /etc/default/rcS, and create /etc/adjtime. This set the system clock
| to be "wrong" if the setting in /etc/default/rcS is not correct.
|
| if localtime is +03:00 from UTC, and hardware clock keeps localtime,
| then system time is 3 hour faster than "correct" time, because
| the localtime is taken as UTC with "--utc" option for hwclock.
I found that "hwclock --adjust" is disabled since util-linux_2.10d-3
(20 Dec 1999) so /etc/adjtime is not created on this first boot from
fresh installed system.
| 3) On shutdown/reboot, /etc/init.d/hwclock.sh saves the system clock into
| hardware (CMOS) clock, under the setting in /etc/default/rcS. If the setting
| in /etc/default/rcS is changed to "correct" before this, and if the system
| clock is not changed (with "date" command), then "wrong" time will be saved
| into hardware clock.
|
| if system time is 3 hour faster than "correct" time, the saved time
| is 6 hour faster than "correct" time. Because this time hwclock treat
| the system time is UTC, and it converts the time into localtime before
| saving the time into CMOS clock since it is not given "--utc" option.
| if localtime is +03:00 from UTC, then converted time is 3 hour faster
| than systemtime (which is already 3 hour faster than "correct" time)
I miss one more point. If UTC=yes in /etc/default/rcS at this time,
then "hwclock --systohc" creates /etc/adjtime with the string "UTC"
written at the 3rd line of this file. And this recorded setting would
not be changed unless the option "--localtime" is explicitly specified
to "hwclock" command.
Therefore, once "UTC" is recorded into /etc/adjtime, the system keeps
to treat the cmos clock as UTC. This is reported for #53808.
This behaviour is described in the manpage of hwclock(8)
--utc
--localtime
Indicates that the Hardware Clock is kept in Coor-
dinated Universal Time or local time, respectively.
It is your choice whether to keep your clock in UTC
or local time, but nothing in the clock tells which
you've chosen. So this option is how you give that
information to hwclock.
If you specify the wrong one of these options (or
specify neither and take a wrong default), both
setting and querying of the Hardware Clock will be
messed up.
If you specify neither --utc nor --localtime , the
default is whichever was specified the last time
hwclock was used to set the clock (i.e. hwclock was
successfully run with the --set , --systohc , or
--adjust options), as recorded in the adjtime file.
If the adjtime file doesn't exist, the default is
local time.
So, if /etc/adjtime does not exist, the default is localtime, but
if it exists, and it has "UTC" at the 3rd line, the setting in
/etc/default/rcS as "UTC=no" is simply ignored because hwclock.sh
in /etc/init.d gives no option for this "UTC=no".
Old slink's hwclock does not set the 3rd line of /etc/adjtime,
nor provide the "--localtime" option. I just have found that
this problem is reported on debian-users@debian.or.jp list
(one of the mailing list provided by Debian JP).
Maybe potato's /etc/init.d/hwclock.sh should use "--localtime"
when the setting is UTC=no, otherwise the setting in /etc/adjtime
(the previous selection) is used.
But if you change your setting before 1st reboot/shutdown of
your installed system (i.e. 2nd reboot/shutdown from the first of
install procedure), the /etc/adjtime has the string "LOCAL" on
the 3rd line.
In <[🔎] NDBBLJECCLJCBKMIKBPBMEEIFAAA.rboylan@mindspring.com>,
at Date: Wed, 2 Feb 2000 16:29:32 -0800,
on Subject: RE: Bug#48866: Time-Zone still wrong,
"Ross Boylan" <rboylan@mindspring.com> writes:
> 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.
In that case, user may use "hwclock" command explicitly.
This "save time on reboot/shutdown" is for the NTP managed hosts.
User of a standalone system may prefer "--adjust" on boot up
(this is now commented out in hwclock.sh).
> 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?
systemtime in kernel (CPU controls) is more accurate than CMOS clock.
At least, I have heard so.
And, if the system uses the NTP (network time protocols) to get the correct
time, then the system time must be the accurate far more than CMOS clock.
On the other hand, setting system clock on running system may cause
some unconvenient for users. window managers for X11 can't detect
the move of pointers for some durations when the clock is gone to future
with leap. so setting only the hardware clock and reboot without saving
the system clock is prefered for some users. Surely some users prefer
the other solution. The decision is done by the maintainer.
> 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.
I think #48866 is initially reported for boot-floppies problem
(can not set /etc/default/rcS) and will be fixed by upload of
the coming 2.2.6 finally. (On BTS, this is closed already.)
And #53808 or another fresh report should be filed for util-linux
related to the problem around /etc/init.d/hwclock.sh ("--localtime" option)
This is just my thought, anyway.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: