Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!umich!terminator!pisa.citi.umich.edu!rees
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Daylight Savings Time and SR10.3
Keywords: DST TZ SR10.3
Message-ID: <509a069d.1bc5b@pisa.citi.umich.edu>
Date: 26 Mar 91 21:38:48 GMT
References: <1991Mar25.202013.27817@bwdls61.bnr.ca>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 21

In article <1991Mar25.202013.27817@bwdls61.bnr.ca>, marmen@bwdla31.bnr.ca (Rob Marmen 1532773) writes:

   Does TZ set the timezone correctly under sr10.3?

Maybe.  You probably still have to reboot after running tz, although this
may have been fixed by now.  You don't have to run offline calendar.

Aegis (if I may use that term) considers daylight offset to be part of the
timezone.  Unix considers it to be a separate offset that gets added to your
timezone, and tries (unsuccessfully) to determine for each timezone which
part of the year this offset should apply.  This effort is doomed to failure
due to the unpredictable nature of politicians in most countries.  It
sometimes works in some parts of the US (Murray Hill and Berkeley), but is
guaranteed to fail in Arizona, Australia, Singapore, etc.

The Aegis approach is the right one, but since it's not Just Like Real Unix,
nobody likes it.

Note that Unix timezone offsets are backwards from standard convention; west
of Greenwich is positive offset, east is negative.  This means the offset
must be subtracted from the system clock to get local time.