nly 1 bit for the century, use that bit to decide whether to report 19 or 20 (for the 20th or 21st century), and do similar reduction on possible values for day of month, day of week, and month. Despite this re-architecture of the RTC, the year filed still was not extended to include the century, which remains outside the automatic update process. This is the root of the problem today. When the year 1999 rolls over to 2000, the RTC will update the year digits (last two digits of the year) to 00, but the century byte, resulting the year 1900 instead of 2000. Many OSs are able to update the RTC while the OS is running. The conditions under which this occurs are OS-dependent. For instance, MS-DOS (and similar OSs such as PC-DOS) use a fairly simple technique to detect most day, month, or year rollovers and to update the RTC. The OS periodically polls its internally tracked time and when it detects a rollover at midnight, it passes a request to the BIOS to update the RTC time and date. However, MS-DOS polls only when idle, so it may not have the opportunity to update the RTC if programs are continuously executing.MS-DOS exhibits a further peculiarity dating back to its roots, which compounds the RTC century rollover problem. For MS-DOS, a significant date marks the beginning of time; January 1, 1980, is the earliest date recognized by any version of MS-DOS. This is due to a data reduction technique used to stamp files with the current date, expressed as an offset from the base date 1-1-1980. The technique reduced the date stamp from a total of 23 bits of information (5 bit for the day of month [1-31], 4 bits for the month [1-12], and 14 bits for the year [0-9999], down to 16 bits. This was accomplished mainly by limiting the year field to 7 bits, and using it as an offset from the year 1980. Under this scheme, any year from 1980 to 2099 can be expressed using offset values ranging from 0 to 119. For instance, the date 1996 is...
