Linux and Y2K

Hardware issues:

All modern PCs incorporate a battery-powered clock which keeps time when the computer is powered off. Early models used a discrete chip such as the Motorola MC146818 or Dallas DS1287. Later models moved the functionality inside the CPU support chipset, while staying register-compatible with these old chips. The register map is based on the IBM AT specification, which does not have a century byte. The chip manufacturers assumed that system manufacturers would handle the century data in software.

Dallas has a good overview of their RTC chip here. These chips have a leap-year counter, which knows that every 4th year is a leap year, including zero. This is actually a mistake, since years divisible by 100 are not leap years. Fortunately, the coming millenium is divisible by 400, which means it is a leap year, so the chips are correct. In 2100 they will get it wrong.

Later versions of the RTC chip by Dallas and other manufacturers incorporate a real century counter, but there is no standard register map, though byte 50 of the CMOS memory is often used. All that an operating system such as Linux can assume is that the MC146818-compatible registers will be present. This is not really a problem, at least until 2170. Unix time started in 1970; thus, two-digit years less than 70 may be assumed to be in the 21st century while ones greater than 70 may be assumed to be in the 20th century.

Although Linux will read the RTC and set the correct system time at boot, is is possible that some old BIOS programs will panic and rewrite the RTC to 1980 if rebooted after 2000. One of the free Y2K testers will probably catch this kind of behaviour.

Clock Drivers

Linux systems of different vintage use slightly different clock drivers. Earlier i386 systems used the "clock" utility to read and set the hardware clock, which queries the MC14681 registers directly. "clock.c" uses the 1970 rule as above.

Later systems use "hwclock", which uses the /dev/rtc device if it exists; if not, it queries MC14681 registers. "hwclock.c" compares the 2-digit year with 38; in 2038 32-bit Unix time will rollover and current 32-bit kernels will fail anyway.

The /dev/rtc device exists on later systems and provides a platform-independant driver (for Intel, Alpha and PPC). Current code uses the 1970 rule. The RTC may be queried using "cat /proc/rtc". A program "rtctest.c" is included in the kernel documentation which tests the timers and alarms in the RTC for Intel.

Dual-Boot Systems

DOS and Windows 95 systems do not access the RTC directly, but read system time from the BIOS. If the system BIOS is not Y2K compliant, it may not roll over correctly, leading to a different date being used by Linux and DOS. You may need to upgrade the BIOS or incorporate one of the TSR solutions in order to fix the DOS time. You may already have an offset in any case - Linux recommends setting the RTC to UTC (GMT) in order to handle timezones and daylight savings time correctly, while DOS may expect local time.

Windows 2000 (NT) reads the RTC directly, and may incorporate a century rule similar to Linux. Expect problems in 2020. See Microsoft's white paper on the subject.

Software Issues

While the Linux system time is OK until 2038, other applications are as subject to Y2K/rollover problems as in any other operating system. For instance, on older systems the standard GNU "date" command could not set the date beyond 2000.

Free software from Silicon Graphics and Digital may be compiled for Linux to scan for 2-digit year constructs in "C" source code and compiled binaries, or other languages such as Perl which use C format constucts. (Using the SGI tools, Linux users users may replace "elfdump -Dsymlib" with "objdump --dynamic-syms".)

Year 2038 Issues

Don't laugh, this is serious. In 2038, the 32-bit system time will rollover and all time-dependant functions will fail in undefined ways, including cron, at, scheduling, logfile timestamps etc. There will undoubtedly still be a few old machines running in 2038.

Legend has it that at one time the electricity grid in Britain was controlled by a Ferranti Argus computer. The machine performed reliably for a number of years, and as time passed no-one was left who understood the code any more, certainly not well enough to port it to a modern machine. As parts wore out, they were replaced by modern components configured to emulate the originals, for instance semiconductor RAM designed to emulate the orginal magnetic core memory.

In a similar way, it's possible that current processors may become enshrined in silicon as macros in programmable devices; vendors such as Altera and Xilinx already offer this kind of thing.

On a more serious note, there will probably be a number of databases created using 32-bit fixed-length fields for timestamp data which will be analyzed after 2038.

See the time page for more Y2K links, details of the NTP network (synchronize your PC to the atomic clock network), etc.

Andrew Daviel, Vancouver Webpages