[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#48866: Time-Zone still wrong



Hi :)

 at Date: Tue, 01 Feb 2000 21:53:40 -0800,
   Ross Boylan <RossBoylan@stanfordalumni.org> writes:

> >Have you "manually changed" it in boot-floppies alternative console (Alt+F2)
> >during initial install stage (boot from root floppy) ?
> 
> Neither my recollection nor my notes permit me to be absolutely sure, but I
> think I made the change after the initial install and reboot.

If the change was done after the reboot, then some work will be
required to reset your clocks, because the system clock is always
saved into CMOS clock at shutdown/reboot.

> >In initial install, /etc/default/rcS is set by dbootstrap in boot-floppies.
> >This is done by asking user with the prompt of "Use UTC in CMOS clock ?"
> >If user answer "yes", then /etc/default/rcS is left untouched, and if user
> >answer "No", then it is changed from "UTC=yes" to "UTC=no".
> 
> Except it wasn't doing that (the original bug).  I think I saw the
> discussion of the fix after the 2.2.5 release, so I've assumed 2.2.5 still
> has the problem but 2.2.6 will fix it.  Correct?

Yes. I hope 2.2.6 will fix this.
>From the code I checked, 2.2.5 did not fix this, I think.

> >Then, after rebooting the installed system, system clock and hareware (CMOS)
> >clock is controlled by /etc/init.d/hwclock.sh using /sbin/hwclock from
> >util-linux package.
> 
> Does /etc/default/rcS play any role after the initial install?

/etc/init.d/hwclock.sh uses the setting in /etc/default/rcS.

if "UTC=yes" is written in /etc/default/rcS, then /etc/init.d/hwclock.sh
does "hwclock --adjust --utc" and "hwclock --hctosys --utc".
The latter extracts the date/time information from the hardware (CMOS) clock,
and set it into system time. (which "date" command shows.)

At reboot/shutdown, /etc/init.d/hwclock.sh does "hwclock --systohc --utc",
and this saves the system time into hardware (CMOS) clock.

So, the process is going in following way:

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.

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 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.

Regards.

-- 
  Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>


Reply to: