Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.sysv386
Subject: Re: Sysv/386 and Daylight savings time
Summary: mutterdosgrumblesillyhardware
Message-ID: <1990Nov13.005923.24658@ico.isc.com>
Date: 13 Nov 90 00:59:23 GMT
References: <16354@s.ms.uky.edu>
Distribution: na
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 28

kherron@ms.uky.edu (Kenneth Herron) writes:
> My machine (a 386-clone running AT&T sysv/386 3.2.1) handled the
> time change properly, but after a system reboot it was off by an
> hour.  Probably this was due to blindly following the battery-backed
> clock.

Right.  When the system comes up, it sets the time off the battery clock.
While it's running, it's got its own idea of correct time, maintained
internally in the GMT 1970-based epoch we all know and love.  As you make
the jump through DST hyperspace, everything is fine...the internal GMT just
keeps incrementing steadily along, and the time-conversion routines deal
with the hiccup just as they should.  But the battery clock time is a "wall
clock" time, so it doesn't make the jump with you; you have to bash it
twice a year the same way you run around and reset all your other clocks.
Otherwise, you get time-warped on the next reboot.

> Is this something I have to live with (horrors!) or is there something
> wrong in my configuration?

Nothing wrong with the configuration.

I've often wished there were an option to keep the CMOS clock on GMT.
Yeah, I know...that would make times look funny in DOS...but I don't use
DOS, so I don't care.  Seems a pity that the problem arises even tho UNIX
is perfectly capable of dealing with the DST silliness.
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   Cellular phones: more deadly than marijuana.