> In article <9512081818.AA27236@gemini.oscs.montana.edu>,
> Michael L. Hitch <osymh@gemini.oscs.montana.edu> wrote:
> >   Or you write an adjkerntz program (or get the FreeBSD one) and run it
> > on startup.  [What happens if you run it from /etc/rc.local, shutdown to
> > single user mode, and then switch back to multi-user mode?  Is the FreeBSD
> > adjkerntz program smart enough to handle that?]
> 
> I wrote a version of this, which was smart enough to handle multiple
> invocations (in fact, it could be run from cron if you like, to readjust
> the offset when DST changes occur), but it was rejected. I still
> disagree with the reasoning, and I still think that the way NetBSD/Amiga
> operates right now is argubaly a bug (it doesn't program the hardware
> correctly, since the Amiga standard is that the hardware contains the
> local time). But, I decided to live with it rather than starting
> another ofshoot OS (sigh...).

	IMHO, the real answer to this dilemma lies in the fact that the Amiga
has 2 clocks.  Under AmigaDos, the only clock that is required to have the
local time is the system clock.
	The only real problem is that AmigaDos, as shipped, doesn't have
a decent way to account for an offset.  Be nice to have a time prefs that
both set _and_ read from the battery backed clock - seems to make a bit more
sense to me - but you shouldn't punish NetBSD for AmigaDos's faults.  Of course,
who'd care if you could just set the clock under NetBSD.
	Any case, AmigaDos doesn't neccessarily expect anything from the
battery clock.  As long as calls to the system clock get the correct time,
ADos is happy.  So, (again, IMHO) the "right" solution is to meet the
needs of the OS that does expect something of the clock.
	If you don't feel like whipping one up yourself, there's a copy of my
brother's system clock setting script in the tools/ dir of your favourite
uni-r mirror.  ftp://<mirror>/pub/NetBSD0Amiga/tools/warpdate.rexx.  Not 
perfect, but it does the job.