Path: utzoo!attcan!uunet!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: re: Date and other wierd problems on an Apollo Dn4500 running Sr10.1
Message-ID: <4da18bc1.1bc5b@pisa.ifs.umich.edu>
Date: 26 Oct 90 16:25:10 GMT
References: <9010260403.AA11351@pan.ssec.honeywell.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 20

In article <9010260403.AA11351@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
  (I think).  YOu can use offsets with 30 minute increments as well (e.g. -4:30)
  if you have weird or funky timezones, and you can even NAME your time zone so
  that the machine calls it by your (up to 4 letter) name.

The 30-minute increment thing is (in my opinion) a bug in
cal_$decode_ascii_tzdif(), which is in kslib.  The author of this routine
has a very small airplane and has never flown it as far away as Nepal or any
of the other countries that are not on 30-minute timezones.  Now that we
have all those troops in Saudi, where time zones are on one minute
increments, it might be time to fix this.

You can get around this by calling the os routine cal_$write_timezone()
directly.  The os stores time zones on disk in one minute increments.

By the way, it isn't immediately apparent, but you must reboot after
resetting the time zone.

Also, why do you have to be root to set the time, but anyone can set the
time zone?