PCs Running Linux: Y2K Readiness Checklist

This page was last updated early during the year 2000 and some or all of its content may thus no longer be current or accurate.

PCs Running Linux: Y2K Readiness Checklist

Summary

Hardware	Many industry-standard (also known as "Intel-based" or "IBM-compatible") PCs have a minor hardware problem affecting their internal clocks: instead of rolling over normally from 1999 to 2000, these clocks will instead revert to a different year. There are a variety of methods available for finding and resolving this problem. The Y2K Hardware Problem Affecting Many PCs It is believed that all major releases of Linux will properly compensate for this problem, and Linux systems will therefore be unaffected.
Operating System	The Linux kernel is fully Y2K-compliant.
Application programs	Check for Y2K compliance.
Data files & data sharing methods	Check for Y2K compliance.

1. Hardware

1.1. We believe that major Linux releases should effectively compensate for the Y2K hardware problem which affects many PCs.

Many industry-standard (also known as "Intel-based" or "IBM-compatible") PCs have a hardware problem affecting their internal clocks: instead of rolling over normally from 1999 to 2000, these clocks will instead revert to a different year (such as 1980).

While this is generally of minor concern, an invalid date could nonetheless cause problems for certain application programs. A small fraction of these problems could potentially have serious impacts. As a result, it's preferable to find and resolve this problem before the year 2000 arrives. The Y2K Hardware Problem Affecting Many PCs describes how to do so. Here's a summary:

You can identify which PCs will be subject to this problem by checking with vendors or by using manual or automated software tests.

There are at least ten different methods you can use to prevent the problem from occurring on your non-compliant PCs. Among these:

Running an operating system, such as Linux and recent versions of Windows NT, that incorporates a date correction feature;
Leaving your PCs turned off over the century transition and using a specific procedure to manually set their dates when they are first started up during the year 2000;
Installing small software programs that automatically correct the date;
"Flash" updating the software in the BIOS chips in your recently-manufactured PCs to make these chips Y2K compliant;
Synchronizing your computers' dates over a network;
Upgrading PCs with BIOS add-in cards or other hardware.

Each of these methods has its own particular advantages, limitations, and drawbacks, which are described in the above document.

As a fallback, you can manually reset your problematic PCs to the correct date when the year 2000 arrives. After doing so, all (or nearly all) of your PCs should then continue to maintain the correct date throughout the year 2000 and beyond.

Linux may be able to correct for many PC Y2K hardware problems

We believe that all major releases of Linux will properly compensate for PC Real-Time Clock (RTC) rollover problems, and that Linux systems will therefore be unaffected.

More information

Uche Ogbuji wrote in the article Linux in the new millennium, LinuxWorld, October 1998:


          Linux reads the time directly from the realtime clock on boot,
          bypassing BIOS routines, but making a similar effort to 
          correct RTC problems. It's still possible, however, 
          that you'll have to reset the RTC manually after the millennium ... 
          (Note that doing so will actually correct the century digits in
          the RTC; so it's probably a good idea to do this even if you have no
          apparent Y2K problems.)

1.2. Check - and if necessary, reset - your Linux system clock.

Several of the commands below refer to the time server ntp2.berkeley.edu, which is operated by the UC Berkeley campus. If you are not affiliated with the campus, you can substitute the name of an equivalent time server at your company or institution, if any, or a publicly accessible NTP time server .

As soon as possible on or after January 1, 2000, check your PC's system date and time to ensure that it is correct. At a command prompt, type:

date

If the system date isn't correct, reset it. If you have Network Time Protocol (NTP) time synchronization installed (see below), you can synchronize your system date with an accurate external time source using ntpdate. At a command prompt, type:

/usr/sbin/ntpdate ntp2.berkeley.edu

If you do not have NTP installed, but your PC has an Internet connection available, you can reset the system date by synchronizing it with another host using rdate. At a command prompt, type:

/usr/bin/rdate ntp2.berkeley.edu

If for some reason your PC does not have an Internet connection available, you can use the date command to manually reset its date and time to the correct values. Refer to your vendor's online or printed documentation for instructions on how to do so.

Some distributions of Linux (notably RedHat ) also have a graphical tool for setting the date; run timetool as root to use it. The automated methods above are still preferred.

1.3. Synchronize your PC's internal hardware clock with your Linux system clock.

After you've checked that your Linux system clock's date and time is correct, it is a good idea to then synchronize your PC's internal hardware clock with this same date and time. At a command prompt, type:

/sbin/hwclock --systohc

1.4. (Optional) Set up Network Time Protocol (NTP) time synchronization on your PC.

As noted above, the Linux kernel corrects for PC Real-Time Clock (RTC) rollover problems. Even so, it is probably a good idea to make sure that the date and time on your PC are synchronized with an accurate time source elsewhere on the Internet.

We suggest that you run the xntpd daemon, included with most Linux distributions, to enable date and time synchronization via the Network Time Protocol (NTP) .

The NTP server on the UC Berkeley campus with which you can synchronize your PC's date and time is ntp2.berkeley.edu. As also noted above, if you are not affiliated with the campus, you can instead use an equivalent NTP time server at your company or institution, if any, or a publicly accessible NTP time server .

2. Operating system

2.1 Linux is believed to be Y2K-compliant.

Linux, and Unix in general, stores dates and times internally as "number of seconds since 1970." Because this representation does not include the year at all, there should be no problems internally with the year 2000. It turns out that the 32-bit number used by most systems to store this data will overflow in 2038, but Linux systems should be safe until then (and will probably be using 64-bit numbers long before 2038).

2.2 Check for the latest information regarding your Linux distribution on your Linux vendor's Web site.

The Web sites of Linux vendors and distributors typically offer pages that offer the most current Y2K status information for their Linux distributions. We suggest you check your vendor's site for the latest updates, if any:

Red Hat

Debian

Slackware

S.u.S.E.

3. Application programs

3.1 Check custom-written programs for Y2K compliance.

Most Unix applications use the same timekeeping mechanism as the operating system--number of seconds since 1970. Such applications are probably Y2K-compliant, as long as they use all four digits of the year that gets returned by the time functions such as gmtime() and localtime().

However, there is another time structure available to Unix programmers which could cause some problems. In /usr/include/time.h, there is a "struct tm" which defines "tm_year" as an integer value of number of years since 1900. This does not create a direct Y2K problem, but 1999 will be represented as "99", and 2000 will be represented as "100". If programmers write code expecting tm_year to return exactly two digits, there could be Y2K problems. For example, a printf statement that explicitly prints the first two digits of tm_year will wind up printing "10" instead of "100", or if you explicitly print "19" and then the value of tm_year, you'll wind up printing "19100" instead of "2000".

Searching for usage of tm_year in your C code or of localtime() in your Perl code will probably uncover most potential Y2K problems. If you use sh, sed, or awk scripts which do date-dependent things, you'll have a more difficult time; you have to make sure that every time you use the year, you use all 4 digits.

Custom-written (or "customized") application programs have been written "from scratch" or else extensively modified to perform a customized set of tasks for a specific customer. Some campus departments are running such applications, which typically have been created by departmental programmers or outside consultants. Often, these programs were built using programming or scripting languages, database management systems, or client/server tools.

Custom-written programs are at considerable risk for Y2K problems. Some of these programs may not work properly in the year 2000, or may encounter problems when handling dates from the year 2000 and beyond. If one or more of these programs are of significant importance to your campus department, it is essential that you find and resolve their Y2K problems. It is also imperative that you begin your work as early as possible, as the process of identifying, fixing, and testing fixes to custom applications can often be very time consuming.

Custom Applications: Finding & Resolving Y2K Problems can direct you to resources to help you find and resolve Y2K problems in custom applications. In particular, you can obtain a great deal of assistance from the Web pages of the UC Berkeley campus's Year 2000 Departmental Customized Applications Subcommittee, which has identified a phase-by-phase process that can guide you in carrying out this work.

This document also provides links to Web pages discussing Y2K issues of relevance to Unix programmers.

3.2. Check off-the-shelf application programs for Y2K compliance.

Most of the software included with Linux distributions is open-source free software. Open-source software tends to have fewer Y2K problems than commercial software because of the peer scrutiny involved in such projects. On the other hand, support for these applications is informal and in some cases non-existent. But on yet another hand, you can probably verify whether a problem exists and fix it yourself if necessary.

Among major free packages, Apache , Perl , and most - but not all - of the GNU software is Y2K-compliant.

For commercial application programs, such as Mathematica, you'll need to check the vendor's compliance statements, and contact the vendor for fixes if necessary.

It appears likely that most commercial off-the-shelf application programs will work fine in the year 2000. However, some application programs are known to have Y2K problems or issues, ranging from minor to severe. If some of these application programs are important to your department or to your own research or instructional work, you'll need to resolve their Y2K problems before the year 2000 arrives. To do this, we suggest that you:

Identify your critical application programs.

Prioritizing: Identifying Your Critical Computers & Software lists representative examples of critical tasks that your computer might be performing, which may help you identify your critical application programs.

To ensure that you're not overlooking any critical programs, Commercial Off-the-Shelf Applications: Finding & Resolving Y2K Problems describes how you can use automated software tools to generate an inventory list of all of the programs installed on your computer.
Determine which of these applications are not Y2K compliant.

You can do this in a variety of ways, including:
- Viewing a list of the Y2K Compliance Status of Selected Off-the-Shelf Applications Used at UC Berkeley .
- Checking vendor Web sites, as well as lists and searchable databases of product Y2K compliance available on the Web.
  
  You can find a summary of these resources in Commercial Off-the-Shelf Applications: Resources for Identifying Y2K Compliance .
- Using automated software tools which report on the Y2K compliance status of your applications.
  
  Software Tools for Finding & Resolving Y2K Problems lists some of the tools you might use for this purpose.
  
  The section on Inventory & compliance status tools in the document Commercial Off-the-Shelf Applications: Finding & Resolving Y2K Problems discusses limitations you might encounter when using such tools.
Resolve problems with non-compliant applications.

Commercial Off-the-Shelf Applications: Finding & Resolving Y2K Problems includes general checklists that can guide you through the process of resolving Y2K problems in non-compliant application programs.

If some of your programs have only minor Y2K issues, you might in some cases be able to continue to use these applications. However, most non-compliant programs will need to be patched, updated, upgraded, replaced, or retired.

4. Data files & data sharing methods

4.1 Check data files for Y2K compliance.

Data files, including spreadsheets and database files, can harbor Y2K problems. If some of these files are important to your department, or your personal research or instructional work, you'll need to resolve their date-related problems before the year 2000 arrives.

The Berkeley Computing and Communications article Checking your data for Y2K problems

provides a overview, and the document Data Files: Finding & Resolving Y2K Problems

describes in somewhat more detail how to check your data files to find and resolve Y2K problems. The following are some key points mentioned in both of these documents:

The primary areas of Y2K-related concern in data files are:

Custom macros, scripts, and user-defined functions.

Some spreadsheet and database files may incorporate custom-written macros, scripts, or user-defined functions which improperly handle dates.
Standard date functions.

Many spreadsheet and database programs provide standard date-related functions which are known to have Y2K-related "usage issues." Examples include Microsoft Excel's =DATE(), Microsoft Access's =DateSerial(), and Lotus 1-2-3's @YEAR().
Dates stored as text or numbers.

Dates stored in spreadsheet cells or database fields as text (e.g., "02/21/15") or integers (e.g., "990405"), may present risks when these values are converted to dates, or when they are compared or sorted.

In addition, we encourage you to take four specific steps to help keep Y2K problems out of your data files

in the future.

4.2. Check data sharing methods for Y2K compliance.

Data shared between application programs could in some cases present Y2K problems. You can find guidance on finding and resolving these problems in Data Sharing Methods: Finding & Resolving Y2K Problems

.

Methods of sharing data which are at risk include documents exchanged via disks, e-mail attachments, and file servers; data copied and pasted via the Clipboard; and programmatic data streams between programs.

To find situations where you'll need to check your data sharing methods for potential Y2K problems, ask yourself three questions:

Do you export data containing century-ambiguous dates, such as "05/13/29", from any of your programs?
Do you import data containing century-ambiguous dates into any of your programs?
Do you share any files (such as spreadsheet or database files) containing dates stored as text or numbers, rather than as dates?

Find something unclear? Missing? Incomplete? Inaccurate? Or even praiseworthy? Send us feedback about this Web site!

This site is provided by the campus Year 2000 Departmental Computers and Administrative Equipment Subcommittee at the University of California, Berkeley.

Copyright 1999 by the Regents of the University of California.
Disclaimer: The University assumes no liability if the information on this page is used for other than University purposes.