Inquiring Minds

Eric Eisenhart eric at eisenhart.com
Tue Nov 5 11:36:46 PST 2002


On Mon, Nov 04, 2002 at 09:13:32PM -0800, Sue Bennett wrote:
> I am puzzled.  I have my machine set up as a dual bootable 
> machine with Windows and Linux.  Why did I have to boot up under 
> Windows in order for Linux to realize that daylight savings time 
> had ended?  The only thing I can think of is that since the 
> machine was initially set up under Windows, and therefore 
> Windows has the lower disk space that the system (hardware) 
> clock is controlled by Windows.  If Linux had been the initial 
> OS would Linux then control the system clock?

The ideal for a machine that does not dual-boot is to tell Linux that the
hardware clock is in GMT and go from there.  Then daylight savings time is
not a problem: Linux simply changes the offset from GMT it uses when
displaying the time to you.

Using GMT (UTC) internally with the choice of PST or PDT happening at
display time means that it's technically possibly to differentiate in this
last time change between the *first* 1:30am and the *second* 1:30am. 
(1035707400 (aka "Sun Oct 27 08:30:00 UTC 2002" aka "Sun Oct 27 01:30:00 PDT
2002") vs 1035711000 (aka "Sun Oct 27 09:30:00 UTC 2002" aka "Sun Oct 27
01:30:00 PST 2002")

Unfortunately, Windows doesn't support anything sane like this and requires
that the hardware clock have its timezone changed twice a year (from GMT-7
to GMT-8 most recently; then back to GMT-7 in the spring).  Windows does
this by changing the clock and recording the fact that it did so.  (This
results in lots of hassle when you've either got multiple windows installs
dealing with one motherboard or windows installs that can't really record to
the hard drive; both are common setups in computer labs, for instance) Linux
can work with a clock set this way, too, but doesn't have a mechanism for
recording that it made the change.  Linux can handle this quite nicely when
it's running through the actual time change.

Basically Linux assumes that either (a) it's running all the time and
handles the time-change itself or (b) if it's off at the time and you don't
use GMT in the hardware, your hardware knows about daylight savings.

With your dual-boot setup, if Linux had picked up on the change, you'd have
probably had the time changed twice and ended up being an hour off the other
way.  With some BIOS setups it'd be possible for Linux to be running, pick
up on the change, record it, then when you reboot, the BIOS picks up the
change, changes the hardware, then Windows boots up and changes the time
again, leaving you with 3 changes and being 2 hours off.

The order of bootup choice in LILO or GRUB and the ordering of the
partitions isn't relevant.  It's simply an issue of which OS is running
when and how each is configured.

Either way, I'd suggest installing the appropriate ntp package for your
distribution.  On RedHat 7.2, at least, I think that involves installing ntp
and listing a few NTP servers in /etc/ntp/step-tickers.  Probably roughly
the same in RedHat 8.0

In other words, you should either, effectively, do this:
hwclock --hctosys
ntpdate
hwclock --systohc

or, if you really care about time:
hwclock --hctosys
ntpdate
start ntpd
(wait until shutdown time)
stop ntpd
hwclock --systohc

I don't know the appropriate RedHat 8.0 way to do it, but on boot-up
"hwclock --hctosys" should run (I think rc.sysinit does that) and on shutdon
"hwclock --systohc" should run.  (or run hwclock --systohc right after the
ntpdate stuff happens...)

(Debian has a separate ntpdate package; install it and put some stuff into
/etc/default/ntp-servers.  That and the /etc/init.d/hwclock.sh that comes in
util-linux ensure that hctosys happens at startup and --systohc at shutdown)
-- 
Eric Eisenhart                                  eric-dot-sig at eisenhart.com
Perl, SQL, Linux and Web            ^               IRC: Freiheit at freenode
Coder, Sysadmin and geek           /e\                AIM: falsch freiheit
http://eric.eisenhart.com/         ---                       ICQ: 48217244



More information about the talk mailing list