> 
> This isn't a problem we can fix, as I understand it. OpenFirmware is
> just painfully broken.
> 
> Resetting the clock by hand is the only solution (and that won't
> even stick past a reboot unless you do it in MacOS, incidentally
> overwriting your nvramrc and OF vars in the process).
> 
> If you'd like to figure out how MacOS X (well, hopefully, Darwin)
> handles this situation, it'd be great to know.


Hmm, my description was a little vague on specifics.

My problem isn't with the G4 Ti resetting its nvram after a reset. 
Rather it is with ntpdate's inability to update the system clock after 
such an event has occured.  The sequence is:

	o	machine boots with clock set to 1901

	o	ntpdate runs, clock adjusted to ~1930

	o	rerunning ntpdate has no effect - we're
		stuck in the 1930s.

I suspect this is an integer overflow/underflow problem rather than an 
OpenFirmware problem.

Try the following, perhaphs on a non PowerPC machine ....

# date 190201010000
Wed Jan  1 00:00:00 EST 1902

# ntpdate ....
12 Jul 10:12:41 ntpdate[563]: step time server .... offset 
994929055.384305 sec

# date
Wed Jul 12 10:12:49 EDT 1933

# ntpdate ...
12 Jul 10:13:00 ntpdate[567]: adjust time server .... offset -0.004044 sec

# date
Wed Jul 12 10:13:03 EDT 1933

# date 200107301325
Mon Jul 30 13:25:00 EDT 2001

(Just remember to restart a few daemons or the system after doing this - 
   cron goes for a walk, postfix dumps core, ....)

	Andrew

PS: On a G4 Ti with OF 3.x, setting the date does correctly update the 
nvram.