The clock handling code was changed in -current on Jan 18
to figure out itself whether the century byte in the CMOS
RAM can be updated from "19" to "20" safely.
This code needs some testing, and it would be Really Nice
if people could check it on various hardware.

There are 2 situations where this code comes into
effect:
1. The machine is booted before 12/31/23:59 and stays
   up until the new year.
2. The machine is shut down over the critical time
   and is then booted.

For most normal PCs, the expected behaviour is:
Case 1: The global kernel variable "rtc_update_century"
gets set to "1" - this can be checked with a debugger.
The century byte will be updated, and the next boot
should not cause time related warnings. After the next
boot, the "rtc_update_century" will stay at "0" and the
century byte will not be touched again.
Case 2: The first boot should issue output like:
WARNING: NVRAM century is 19 but RTC year is 00
WARNING: Setting NVRAM century to 20
The century byte will be updated, "rtc_update_century"
will stay at "0" and the century byte will not be touched
again.

Some PCs, most notably IBM products, don't have a century
byte at the expected location. These machines will print
something like:
WARNING: NVRAM century is XX but RTC year is YY
on each boot. "rtc_update_century" CMOS RAM location should
stay at "0" and the CMOS will be left alone -- unless
the 1/256 chance hits that XX==19.
If this should happen and cause trouble (BIOS checksum errors
on next boot), the "rtc_update_century" can be set to "-1"
permanently in /netbsd with gdb's help - this will prevent
the CMOS RAM from being touched.

So, do your machines behave as expected?

(To get the century byte back to "19" after such an experiment
you'll need either the BIOS "set time" function, or to set
"rtc_update_century" to "1" manually with a debugger's help.)

Thanks!
Matthias