The "Y2K Problem", also called the "Year 2000 Problem" or the "Millennium Bug", is the label assigned to certain anticipated digital equipment processing discontinuities resulting from the breakdown in the year 2000 of certain expedients and assumptions made in designing date operations. Most notably, these problems involve date operations designed to use 2-digit years and assume a 1900 base.

The date sensitive digital equipment that we have come to rely on includes computers and other equipment containing embedded Programmable Logic Devices (PLD). Y2K is a problem to the extent that discontinuities in date processing by this equipment is a problem.

On Personal Computers (PC) alone, date data is entered, manipulated, stored, calculated, sorted, sequenced, displayed, and reported. Each of the following aspects of a PC can affect successful date processing through Y2K.

• BIOS chip
  • Basic Input/Output System for PCs
  • May have trouble rolling first two-digits of year from 19 to 20.
• RTC chip
  • Real Time Clock for PCs
  • Keeps track of date in two-digit format.
• Operating System
  • Interface between software and hardware.
• Software Applications
  • Incorrect handling of new millennium, year 2000 leap year, and special date fields.
• Software Runtime Libraries
  • Support software applications.
• Custom Code
  • In-house crafted code and work arounds.
  • Frequently poorly documented and using non-standard programming techniques.
  • Includes spreadsheets.
• Data Interfaces
  • Network or other connections to legacy systems.

NIST ITL Bulletin - Millenium Rollover: The Year 2000 Problem
NIST ITL Bulletin - What is Year 2000 compliance
BSI DISC Definition of Year 2000 Conformity Requirements
Robert Sandler's The Year 2000 FAQ
Doug White's FAQ About the Y2K Problem

National Institute of Standards and Technology (NIST) Y2K Web Site
US Senate Special Committee on the Year 2000 Technology Problem
US Small Business Administration Help for the Year 2000
The Year 2000 Information Center / Millenium Bug
Duh-2000: A Collection of Misunderstandings about Y2K

RFC 2550 - Y10K and Beyond
Mike's Y1K Study

This statement is in response to inquiries regarding the effects that the Year 2000 Changeover will have on RXN Communications and is subject to change. We have established a Year 2000 Readiness Program and our goal is to mitigate risks presented by the Year 2000 Changeover to our customers, suppliers, and facilities.

We are assessing our existing computer systems and network components to identify potential Year 2000 Changeover problems and issues. Through our internal assessment, we have thus far determined that the majority of our systems are ready for the Year 2000 Changeover. We will continue our assessment and testing and, where appropriate, renovate or replace components so that our mission critical systems will be Year 2000 Changeover ready.

Although RXN Communications will continue to make every reasonable effort to ensure that our services will not be impaired by the Year 2000 Changeover, please remember that these services are provided in conjunction with third party computer hardware, software, utilities, and telecommunications services. Because of our dependence on the Year 2000 Changeover readiness of these third party providers, we can not warrant that our customers or vendors will not in some way be affected by the Year 2000 Changeover.

If you have any questions or concerns about this Year 2000 Readiness Disclosure Statement, please contact us at support@rxn.com.

RXN Year 2000 Readiness Program Assessment Overview as of 29 Apr 1999:

• Server Hardware
  • SGI Hardware is "Y2K-compliant" when running at least SGI IRIX 6.5.X.
  • Dell. Flash BIOS upgrades are available for servers to "be made Year 2000 Compliant".
  • Seagate. Our Seagate data storage products "perform no date manipulations on data and have no date logic embedded in firmware or microcode. Thus all Seagate storage products are fully Year 2000 compliant."
  • HP. Our HP printing equipment is "Y2K Compliant".
  • Nanao(Eizo). Our Nanao products will "continue to operate unaffected by the changeover to the year 2000".
• Server Software
  • SGI IRIX. SGI IRIX 6.5 "is Y2K compliant".
  • BSDI BSD/OS. "The current version of BSD/OS (4.0.1) does not use system dates that will encounter Y2K problems. Systems that store dates as 96/08/02 or 960802, for example, may have problems coping with dates like 00/01/01 or 000101. BSD/OS does not store dates in this manner. BSD/OS, like UNIX and other UNIX-like systems, stores its dates as a 32-bit integer representing ``the number of seconds since the UNIX epoch'' which was midnight, January 1, 1970 (Coordinated Universal Time). Leap years are all handled correctly. This means that there should not be problems with the internal clock and date storage until the year 2038. BSDI will provide a longer term solution far before this date arrives."
  • Linux "As a general rule, Linux is Year 2000 compliant. As with most Unix-like operating systems, Linux currently is written with a 32-bit date representation. This suggests that Linux will have difficulty in the year 2038 unless the kernel and associated source code are migrated to 64-bit implementations capable of handling dates for another two billion years. Given that Linux developers have forty years in which to address the problem, it is very likely that solutions will be implemented long before the year 2038."
• Time References
  • NTP. "...incorrect time values due to the NTP timescale, protocol design and reference implementation are highly unlikely. However, it is possible that external reference time sources used by NTP could misbehave and cause NTP servers to distribute incorrect time values to significant portions of the Internet."
  • ns.nts.umn.edu
  • ntp1.cs.wisc.edu
• Routers, Hubs, Modems
  • Ascend. "...product is defined as a part, product, or component that does not apply to Year 2000 requirements because it has no date capabilities. A date cannot be set or changed on the part, product, or component."
  • 3COM. Our hubs are not date sensitive and are "Y2K OK" in all software versions.
  • DIGI. Our DIGI concentrators are "Year 2000 Compliant".
  • USR. Our modems are not date sensitive and are "Y2K OK" in all software versions.
• Telecommunications
  • USWEST. "We have evaluated the readiness of our switches and made substantial progress in upgrading them for the Year 2000. At the end of 1998, more than 80 percent of our switches were Year 2000-ready. The remaining 20 percent will be ready by July 1999." and "We are testing and upgrading the computer software we use to support the network and our business operations, such as network monitoring, data management, and billing. At the end of 1998, we had as much as 70 percent of our critical computer applications tested, upgraded, and operable for Year 2000 readiness. The rest will be completed by July 1999."
  • AT&T. "AT&T is committed to completing the deployment of all customer-impacting systems and network elements in live production environments by June 30, 1999."
• Internet Connectivity
  • gofast.net "Our goal is to mitigate risks presented by the Y2K problem and maintain business continuity."
  • mr.net "Our goal is to mitigate risks presented by the Y2K problem and maintain business continuity."
• Electrical Utilities
  • NSP "We are on target to remediate all critical applications by June 30, 1999 and to devote 1999 to working on final interface issues, remediation and testing lower priority applications, and re-testing and fine-tuning critical items."
  • APC "APC has determined that all hardware products that APC manufactures for sale are Year 2000 compliant."
• Water, Sewer, and Civic Utilities
  • Minnetonka "City staff is currently in the process of evaluating the organization as a whole to determine that we are prepared to continue operating through the century rollover without any disruption in services to our residents."
• Heating Utilities
  • Reliant Energy/Minnegasco "Our gas distribution system is designed to operate safely and independently in the event computer systems fail, whether now or on January 1, 2000. Also, by the end of 1998, all of our major computerized applications which affect customers were modified, as necessary, and tested to be sure they are Year 2000 ready. As a result, our information technologies should continue to function properly and accurately process bills and other customer information byond the Year 2000."

The following reference information is provided for background only. You should independently confirm any information that you intend to use for decision making.

The Real Time Clock (RTC) stores the system date under battery power when the system is powered down. Quoting from the Microsoft Windows Operating System Interactions with BIOS and Real Time Clock white paper:

Before IBM made the Real Time Clock (RTC) chip standard equipment on its PC AT in 1984, users were prompted to enter the date manually every time they turned on their computers. PCs since then have essentially duplicated the RTC chip, which may or may not have Year 2000 functionality.

The RTC chip is battery powered to ensure it can keep time even when the PC is turned off. The chip itself updates time, day, month, and 2-digit year. It typically contains seven registers that store time and date values. Six of the registers are updated automatically. Each one of them stores a different value: seconds, minutes, hours, days, months, and years. The year register stores the last two digits – "99" in 1999 or "00" in 2000. A seventh one —called the century register—stores the first two digits of the 4-digit year. The century register reads either "19" in 1999 or "20" in 2000 and is not updated automatically. It will change only if updated by either the BIOS or the operating system.

Many hardware manufacturers do not support direct access to the RTC. This is because there is no standard location for the century register in RTCs. For example, the RTC chip in most PS/2 computers stores the century value in a different location than the RTC chip found in other types of computers. Some Year 2000 testing applications do access the RTC directly and have detected anomalies. However, Microsoft is not aware of any non-test applications that directly access the RTC. In general, applications should always use defined application program interfaces (APIs) or BIOS interfaces to obtain date information.

RTC, BIOS, and the boot sequence

BIOS loads the date from the RTC before the operating system is loaded. Quoting from the Microsoft Windows Operating System Interactions with BIOS and Real Time Clock white paper:

The RTC and BIOS functionally support each other so it is advisable to view their Year 2000 readiness as a combined unit. Most RTC rollover issues are remedied by the BIOS, while still others are remedied by the operating system.

In older PCs, the BIOS software may not automatically roll over the century. In that case, the century register in the RTC will remain at "19" when the date should roll from 1999 to 2000. Some PCs have BIOS that do not recognize the years between 1980 - 1993 or 2000 -– 2093 as valid dates so the RTC century register will not rollover to 2000. These BIOSes also will change the date to some other non-current date. In some other PCs, BIOS Setup may not accept dates after 12/31/1999.

The computer startup program and POST sequences are summarized below to enable you to better understand how date errors are passed to the operating system.

When the system is turned on, it "boots-up." The boot program is stored permanently in a set of read-only memory (ROM) chips. A signal triggers the CPU to initialize its registers. The signal sets the CPU’s program counter to the address of the instruction that starts the BIOS boot program, that in turn invokes a series of system checks, known as Power On Self Tests (POST).

During POST the CPU sends signals to system components to ensure they are all functioning properly. If they are not, error messages (or beeps) indicate which components need attention.

POST validates the system’s RTC for consistency and notifies you when something is obviously wrong. For example, if the battery that powers the clock has failed, POST notifies you and resets the date values.

Next POST initializes the display adapter. Tests are then run to determine the amount of memory on the system, to ensure that the random-access memory (RAM) chips are functioning properly, to ensure that the keyboard is attached properly, and to determine if any keys have been pressed.

Next POST detects which drives are available and records any changes to the basic system configuration. POST then identifies the BIOS code of any additional components and incorporates them into the system’s BIOS program.

The next step in the boot process is loading the operating system from disk. Note that the RTC and BIOS are invoked before the operating system is loaded. This is a key factor in some rollover-error cases.

There are three (3) common BIOS errors encountered during Y2K. These are described in the Microsoft Windows Operating System Interactions with BIOS and Real Time Clock white paper:

• Case 1
  • "The century rollover code is missing from the BIOS program and the RTC century register is not updated."
  • "During POST, the BIOS may not map invalid dates like 1900 to 2000. For example, if the PC was turned off during the transition from the year 1999 to 2000, the century register will still be set to "19" (1900) when the machine is turned on."
  • Date will be set automatically by WindowsNT, Windows98.
  • Date will need to be set manually once from within Windows95, Windows3.1, and DOS.
• Case 2
  • "The BIOS only allows years within a specific range."
  • "During POST, the BIOS may not allow certain valid date ranges. For example, one commonly-used BIOS chip allows the years 1994 - 1999 and 2094 -– 2099, but does not allow the years 1980 -– 1993 or 20 00 – 2."
  • Date will need to be set manually each time the system is booted from within Windows98, Windows95, Windows3.1, and DOS.
• Case 3
  • "BIOS Setup does not recognize dates after December 31, 1999."
  • "When running BIOS Setup, a date of 1/1/2000 or greater may not be accepted."
  • Date will need to be set manually once from within Windows98, Windows95, Windows3.1, and DOS.

The following reference information is provided for background only. You should independently confirm any information that you intend to use for decision making.

Two-digit date storage

The most common and most damaging problem occurs when software has been written to store and/or manipulate dates using only two digits for the year. Calculations built upon these dates will not execute properly because they will not see dates in the 21st century as being larger numbers than those in the 20th century. Example: 2000 - 1998 = 2 but 00 - 98 = -98. (or 98 if the application does not allow negative numbers). The result of this might be that your accounting software sees all accounts receivable as overdue due to the fact that no customers have paid in 98 years.

The two-digit date convention assumes that the century is "19." This assumption was regarded as a necessity in the early days of commercial computing because of the high cost of computer storage and memory. Today, the usage of two-digit dates is perpetuated by the sociological context in which dates are referenced in our daily lives. Individuals choose to use two-digit dates due to the fact that the human mind handles dates contextually whereas the computer requires the explicit expression of dates.

Leap year calculations

Leap years are calculated by a simple set of rules. Unfortunately, there are systems and applications that do not recognize the year 2000 as a leap year. This will cause all dates following February 29, 2000 to be offset incorrectly by one day. The rules for leap year calculations are as follows. A year is a leap year if it is divisible by four, but if it is divisible by 100 it is NOT a leap year, but if it is divisible by 400 it IS a leap year. Thus, the Year 2000 is a special case leap year that happens once every 400 years.

Special meanings for dates

The third main Year 2000 problem is more commonly found in older code bases. In order to write more efficient code which allowed for the use of less memory, date fields were sometimes used to provide special functionality. The most common date used for this was 9/9/99. In some applications the use of the special date meant "save this data item forever" or "remove this data item automatically after 30 days," or "sort this data item to the top of the report." Within each organization, special date codes may have been used differently. This is one of the main reasons that no single tool can locate all uses and/or misuses of date data.

Technically, the problem is simple to understand. The solutions to the problem tend to be fairly simple as well. The scope of the problem, however, makes it difficult. Every piece of hardware, software, and embedded system must be taken into account. Everything from mission-critical central accounting systems to small convenience applications must be examined for date-handling and how those dates might affect the rest of the environment.

Specific information about your software and Y2K can be found at your software producers web sites:

MicroSoft TechNet - Year 2000

If you run a business, Y2K legal repercussions require proactive action in order to avoid liability and maximize recovery. Legal risks include the potential for breach of contract suits, class action litigation, tort exposure, statutory exposure, customer fraud exposure, and directory liability suits. A failure to act invites liability and may waive rights of recovery.

     November 2, 1997 - Overflow HP/Apollo Domain OS

     January 1, 1998 - to ensure that the digits "98" do not trigger a
     red flag, other program subroutine(s), or cause a processing error

     January 1, 1999 - to ensure that the digits "99" do not trigger a
     red flag, other program subroutine(s), or cause a processing error

     FY2000 for business and industry - Depending on the business the
     FY could start on March 1, 1999, July 1, 1999 or match the
     government fiscal year of October 1, 1999.

     August 22, 1999 Overflow of "end of week" roll-overs (e.g. GPS)

     September 9, 1999 (9/9/99 or possibly 9999) - to ensure that the
     digits "99" or "9999" do not trigger a red flag, other program
     subroutine(s), or cause a processing error

     October 1, 1999 - first day of Fiscal Year 2000

     January 0, 2000 - - to ensure that this date is NOT processed
     (Some applications do have this problem and counts January 0 as
     the day before the 1st)

     January 1, 2000 - key date in any compliance testing

     January 3, 2000 - first full work day in the new year

     January 10, 2000 - first 9 character date

     February 28, 2000 - to ensure the leap year is being properly
     accounted for (yes, 2000 IS a leap year!!!)

     February 29, 2000 - to ensure the leap year is being properly
     accounted for

     February 30, 2000 - - to ensure that this date is NOT processed

     February 31, 2000 - - to ensure that this date is NOT processed

     March 1, 2000 - to ensure date calculations have taken leap year
     into account

     October 10, 2000 - first 10 character date

     December 31, 2000 - 366th day of the year

     January 1, 2001 - first day in the 21st Century

     January 1, 2001 - Overflow for Tandem systems

     After January 1, 2002 - to ensure no processing errors occur in
     backward calculations and processing of dates in the 1980s and
     1990s at this point in time

     February 29, 2001 - to ensure that this date is NOT processed as a
     leap year

     February 29, 2004 - to ensure that this date is processed as a
     leap year

     January 1, 2010 - Overflow ANSI C Library (Note: This event is
     alleged to be a valid Y2K problem date. I do not have any
     additional information on this claim)

     September 30, 2034 - Overflow of Unix time function

     January 1, 2037 - Rollover date for NTP systems

     January 19, 2038 - Overflow of Unix systems

     September 18, 2042 - Overflow of IBM System/360

     February 28, 2100 - last day of February - NOT a leap year