I found that hwclock changes the Century Byte (50) in an i386 when a --set
is done, but only when hwclock does _not_ use the rtc driver for doing
this. The rtc driver does not set (or access) the Century Byte at all.
Instead, the rtc driver uses a "windowing" technique to interpret 70-99 as
19xx and 00-69 as 20xx.
Thus when you set the year to 2000 with hwclock (with hwclock using rtc),
the hardware (RTC/CMOS) will save it as 1900.
Most PCs have a RTC that does not change the RTC/CMOS Century Byte by
itself. Newer PCs (so-called 2000-compliant PCs) have a BIOS that changes
the Century Byte from 19 to 20 whenever it detects a low-value year (such
as 00). These new BIOSes will do this at startup time (in POST), and
probably also whenever a time/date read or set is done using BIOS. Older
BIOSes donīt do this (and these were sold even in 1997). The rtc driver
does not use BIOS to access RTC.
I suggest that the rtc driver should be modified, so that it always sets
the Century Byte when setting a date. Perhaps it should also return the
hardware RTC/CMOS century when used to read the RTC time - this will make
Linux less 2000-compliant by itself, but more honest. I donīt know enough
of Linux tell which is best.
A related question is whether or not Linux should automatically change the
Century Byte whenever it detects a (read: this) century change. This
function is said to be implemented in Windows 98 and NT (3.51 SP5 and 4),
but I have no details. I have not tested it.
If the RTC/CMOS century and year are e. g. 1900 and you boot your PC with
DOS (or Win95, or Win3.x), DOS will recognize an out-of-bounds date, set
the year to 1980 (the Beginning of Computing) and return an error code of
January 4, setting the date to 01/04/80 (RTC/CMOS too). Next time you boot
Linux ...
Regards,
Anders
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/