I've done some experimentation with pmax clock code.
As best I can tell, the PROM is checking the date in the RTC
at boot time.  If the year is anything other than 1972 or 1973,
the PROM resets the date in the Dallas/mc<whatever> clock chip
to 1972-01-01.

that's why the original 4.4bsd/pmax code used an "year offset" of 20
years, and why the pmax code has been using an offset of 22 years.
Those offsets worked for 1992/93, and 1994/95; but it's 1996 now.

When machines get rebooted in '96, the PROM sees a date sometime
in 1974, which it beleives is a symptom of losing battery power,
so it sets the chip to 197-01-01, which the kernel interprets
as being 1994.

For now I'm hacking the year offset to be 24 years, which
more-or-less works.

The only viable long-term solution seems to me to be to use the clock
chip as a time-of-year clock, holding the time in seconds since Jan 1
in the current year. (the time-in-seconds will, of course, be held as
a date sometime in 1972; it's the corresponding number of seconds we
want.)  This of course means taking the base-time (seconds since
epoch) and converting it to a year, and seconds in the year;
and converting the `date' in the RTC to seconds in the year, and
comparing the last two.  Updating the RTC means computing
year and seconds-in-year, and converting the latter to a date
sometime in 1972.

(We could always put the chip into 1972 for leap-years and 1973 for
non-leap-years, but I don't see that that saves any work in
conversions over the scheme above.)

If someone wants  to take this on, I'd be most grateful.

(I don't suppose the Alpha port does this already anywhere??