jk12@doc.ic.ac.ukProblems with Hardware and Software
by
There has been much discussion of the information systems challenges facing most companies as the year 2000 approaches. Most of the attention has centered on the significant problem of identifying and updating business software applications to handle the century rollover. Another aspect of the problem, however, has received less attention. Most of the personal computers (PCs) in operation today will be unable to advance their hardware-based system dates to the year 2000 without intervention through the system BIOS.
It is most likely to happen to PCs that are powered off at the time of the century rollover, and then powered up on January 1, 2000 or after. Unlike the larger software applications problem, the system date problem is quite easily remedied. The ramifications of not fixing it, however, can be major. For instance, many applications rely on the system date for accurate processing. Additionally, network operating systems (NOSs) and workgroup applications base many automated network functions on the server system date.
Most PCs maintain two system dates--one in the CMOS real-time clock (RTC), a chip located on the system board that maintains the date and time even when the system is powered off, and one in the operating system (OS) software. The RTC system date can be set and retrieved using BIOS calls. When the OS is booted, it normally initializes the current date from the RTC through a BIOS call. Once initialized, the OS maintains the system date as long as the system is powered on. Conversely, under certain conditions, most OSs can update the RTC date while the system is running.
This behavior applies both to standalone PCs and PC-based network servers. In contrast, networked PCs can behave somewhat differently, depending upon the NOS. Many NOSs are configured so that when a PC logs in to the network, the local OS can initialize the current date from the NOS so that the server controls the system date on its attached networked PCs.
The system date is maintained correctly as long as the RTC is able to automatically update to the correct date or the OS has an opportunity to update it. However, the century rollover challenges this process because, under certain conditions, the PC RTC will not be updated correctly to the year 2000. This is due to an inherent flaw in most RTCs dating back to the early days of the PC, as well as peculiarities in the system dates of some of the most common OSs.
Furthermore, as more of the RTC and nonvolatile storage functions have been folded into optimized chip sets, additional data reduction has been applied to further simplify the information. For example, some chip sets would use only 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 rearchitecture of the RTC, the year field 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 date) to 00, but not the century byte, resulting in the year 1900 instead of 2000.
Creating a software patch that will allow your computer to be reset to 1900 and then every call to that machine 'date' would be intercepted and have 100 added to the year that is passed back to the software making the 'date request'...
Trouble is that is NOT always possible with applications that request the system date at a 'low level' that cannot be trapped by the operating system.
Well, It affects virtually all kinds of hardware, platforms, and systems! Don't limit your thinking just to computer software. There are certain chips that cannot process into the Year 2000. There are certain devices such as UPC devices, card readers, etc. that cannot add digits to date fields (take a look at your current credit cards). Client/server, PCs, mainframe, mini's, telecommunications, networks, elevator systems, missile launch systems, traffic light systems, telephone systems, mail delivery systems and more will be impacted (to a larger or smaller extent) by Year 2000 problems depending on when and how they were developed. The two-digit-year-field can also be found in compilers, operating systems, JCL, embedded file names, queries, archives, data bases, screens, reports, applications, software utilities and data.
The MacOS operating system and Apple Macintosh computers do not have problems with the year 2000. All MacOS operating system date and time utilities have correctly handled the year 2000 since the introduction of the Macintosh. The original date and time utilities (introduced with the original Macintosh 128K in 1984) used a long word to store seconds, starting at January 1, 1904. Starting with a long word of seconds since January 1, 1904 means that dates run out at 6:28:15 a.m. on February 6, 2040.
VMS is YEAR 2000 Compliant. VMS uses a bizarre time format which is microseconds. It allocates 64 bits of information. Because 64 bits is so large, even with microsecond resolution this timer won't overflow for another 584,000-odd years.
UNIX/ANSI C also defines a "struct tm" structure for broken-out time fields. The year is offset from 1900; some libraries have improperly handled years outside of the range [00..99].
Also, _many_ application programs have problems with this. Some accept "100" to indicate 2000. Some will print back dates like "01-01-100" (instead of "01-01-00"). Others will complain about your ignorance -- years should be two digits only. Other than that, this time structure has no meaningful "important" dates. Who cares if the year will roll over in 2 billion years?
The system does some odd things in Y2K. Some dates come up as 01/02/100 on the screen when the record is created, but are stored as 01/02/10. Your application is using tm_year to retrieve the current year. Just so happens that tm_year starts in 1900, where 2000 is year 100. Your application is probably using a sprintf into a char[2] field. Yes, you're are getting corrupted memory on the byte following that char[2]. Need I say more?
The C problem has been overlooked. . . . Oh well, if Y2K was that easy (like so many "experts" say), we wouldn't be scared to death of what may occur 01/01/2000.
Unix keeps the date and time as the number of seconds that have elapsed since 0000 hours UTC, January 1, 1970. It keeps this count in a 32-bit signed integer. The count will overflow on January 19, 2038, when the number of seconds reaches 2,147,483,647, the maximum number that can be represented in a 32-bit signed integer. All versions of C and C++ use this same format for certain library functions. This [rollover in 2038] is more serious than Y2K. UNIX is heavily embedded in our infrastructure, and this format is now standard for most C/C++ programs. That means it is extremely widespread.
Dr. Tom of the Worldstreet Journal software company and a well-known expert on OO topics reports that object-oriented languages such as Objective C, Smalltalk, Eiffel, etc. should be among the least expensive if the applications are well formed and the date calculations are handled by formal class libraries. Indeed, since object-oriented business applications are comparatively recent, many may already use adequate space for all date digits and hence the year 2000 problem may not be present in some OO applications.
On the other hand, the OO paradigm has a steep learning curve and there may also be OO applications with incorrect date calculations "hard coded" into the application just as they would be in procedural languages.
jk12@doc.ic.ac.uk