Subject: Re: Timezones
To: None <>
From: Michael L. Hitch <>
List: amiga
Date: 09/30/1994 10:27:51
On Sep 30,  9:12am, wrote:
> > Set the time on the amiga side to GMT and then on NetBSD link 
> > the /etc/localtime to the respective /usr/share/zoneinfo/* timezone file.
> But that is the problem: Either you have on both sides the right time,
> but then you have NetBSD set up for a wrong timezone, or you have the
> wrong time on the ADos side, but the right time *and* timezone with NetBSD.

  On one of my systems, I have the Amiga clock set to GMT and run an Arexx
script to adjust the local time.  It has a slight disadvantage in that it
doesn't handle daylight savings time, which means I have to remember to
edit the script a couple of times a year.

> I haven't tried this yet, but maybe it is possible, to correct the time
> while booting (somewhere in rc.local), and resetting the time when
> shutting down (somewhere in fastboot, or whatever your favorite way to
> exit NetBSD is). AFAIK it is not (yet) possible to set the battery backuped
> clock from NetBSD, so the second step is probably not necessary.

  One problem with this is that rc.local only gets execute when starting
up multiuser mode, so if you boot up single user, the time won't get
adjusted unless you manually do it.

> As this may result in inconsistencies while booting, maybe a kernel entry
> stating the difference between local timezone and GMT would help, so that
> NetBSD will read the internal clock, convert the time to GMT and then
> you could change this value with /etc/localtime. This is somewhat
> complicated, but you have correct times and timezones with both OSs.

  The config files still have a timezone adjust value, which isn't used
anywhere as far as I could tell.  It also has a DST parameter.  The timezone
offset would be easy enough to use to adjust the time, but handling DST is
much more complicated due to all the varous different rules.  This method
would require users to configure their own kernels to get the correct time,
unless they just happened to be in the same timezone as the kernel was
configured for.


Michael L. Hitch			INTERNET:
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA