>> The SRM console may expect the NVRAM to have the date in its native
>> OS's format...
> And, if this is the case, then we should almost certainly switch our
> date format, because SRM is the console we have to appease.

I looked at sys/arch/alpha/alpha/clock.c (thank you, whoever it was
that mentioned that!) and found

#ifdef CLOCK_COMPAT_OSF1
/*
 * According to OSF/1's /usr/sys/include/arch/alpha/clock.h,
 * the console adjusts the RTC years 13..19 to 93..99 and
 * 20..40 to 00..20. (historical reasons?)
 * DEC Unix uses an offset to the year to stay outside
 * the dangerous area for the next couple of years.
 */
#define UNIX_YEAR_OFFSET 52 /* 41=>1993, 12=>2064 */
#else
#define UNIX_YEAR_OFFSET 0
#endif

Someone else said

> The two Console interfaces available (ARC and SRM) store the year in
> the hardware NVRAM clock with offsets that differ by 20 years.

which is probably related to the kludge referred to in the comment I
quoted above.

In any case, I built a kernel with CLOCK_COMPAT_OSF1.  First boot, I
got a whine about an insane date in the clock chip, but after checking
the clock (didn't need to change it) and rebooting, everything is fine.
No more timewarps to 2019 upon power-cycling the machine.  Maybe
CLOCK_COMPAT_OSF1 should be turned on by default?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B