🚀 go-pugleaf

In article <636qru$o0j$1@gidora.kralizec.net.au>,
Nick Andrew <nick@zeta.org.au> wrote:
>In <636580$8sg@padre.unico.com.au> david@unico.com.au (David Goh) writes:
>
>>*nodnod* This is correct... *but* the reason why the machine had to be
>>on when the time changed over for him, is that he's probably got his
>>CMOS clock storing localtime, rather than UTC (GMT).
>
>I wondered if this was the case (and why anybody would want to do that :-))

This allows people to dual-boot broken operating systems[1] which
expect the CMOS clock to store localtime.  Some distributions
(Slackware at least) install this way by default :-(

Linux copes with CMOS clocks which hold localtime by converting the
value read at boot time to UTC (via ``/sbin/clock -s'').

Now this kludge only works if the CMOS clock has the correct localtime
at boot *including* daylight saving corrections.

In Sydney and Melbourne for example, the value read from a localtime
CMOS clock will now be adjusted by -11 hours at boot.  If that clock
still holds standard time (-10), the system's UTC value will be out by
one hour.

>but still couldn't think of a scenario where it would matter that the
>machine was not actually operating at the transition point.

It doesn't.  The machine in question could have been operating
correctly through the transition, but the next time it was re-booted
the clock would have been out[2].

[1] Such as Lose95.
[2] Unless ``clock -w'' was called before shutdown, or ``clock -a'' is
    set up to run periodically.

Regards,
-- 
Brendan O'Dea                                        bod@compusol.com.au
Compusol Pty. Limited                  (NSW, Australia)  +61 2 9809 0133