Y2K in Specifications

just as it is wrong to specify that a building be made of nothing but green cheese from the moon, it is wrong to specify systems that may not be available

Related articles

y2k - A Matter of Time: what it's all about, other similar problems

y2k plus 1: aftermath of the  problem

y2k in specifications: what's wrong with typical y2k requirements

We have heard a lot about the Year 2000 (Y2K) problem and how it will affect the financial world, but there has been little discussion of the impact on the construction industry.

It is likely that most architects, engineers, owners, and building product suppliers have gone to their attorneys for advice. Unfortunately, many well-intentioned attempts at specifying Y2K-compliant building equipment and systems are too broad in their scope.

the devil is in the details

The major issue, at least in popular perception, is the lack of a widely accepted definition of the problem. Those issues that are directly related to the year 2000 are easy to define, and can be addressed without a great deal of difficulty in the construction industry. As long as a building system reacts properly to the two key dates associated with the year 2000 - 1 January and 29 February - it should be considered "Y2K compliant" in the strict sense of the term.

Unfortunately, a common definition goes something like this:

Year 2000-compliance shall mean that performance and functionality will not be affected by dates prior to, during, or after the year 2000.

Some people like to embellish this a little by including references to leap year calculations in 2000, or by adding terms like software, hardware, systems, products, and so on, but add little to the above definition. Ignoring its content, this is a good specification. It is simple, direct, and easily evaluated. All it requires is that no date - note that there are no exclusions - will produce any problems.

This definition virtually assures non-compliance. The year 1582 introduced a major anomaly in the calendar (see GUI Bytes - a matter of time); it is unlikely that building systems will be able to correctly calculate dates earlier than 15 October 1582, and would therefore fail to comply with the first part of the definition.

Similarly, it is unlikely that building systems will correctly calculate all future dates. Even if the year 2038 problem is addressed, no manufacturer can guarantee that all future dates will be properly handled.

Just as it would be wrong to specify that a building's structure be made of nothing but green cheese from the moon - because the technology doesn't exist today - it is wrong to specify equipment and systems that may not be available.

The broad definition is inherently faulty, and should not be used. A narrower and more achievable definition would focus on the problems directly associated with the year 2000, including correct calculation of 1 January, 29 February, and related issues, and require correct calculation of dates beginning at the time of installation.

who's to blame?

Some Y2K compliance specifications pass responsibility for compliance on to the contractor. In itself, this is not unusual, as the contractor is normally responsible for selecting products that comply with the contract documents. In this case, an unreasonable burden is placed on the contractor, who is probably less knowledgeable about this issue than the architect, the engineer, or the manufacturer.

Construction product suppliers rely on the hardware and software manufacturers who produce system components. Many systems comprise products from a variety of suppliers, further complicating compliance. A quick review of Y2K-compliance statements issued by computer hardware manufacturers, software producers, and building system suppliers indicates that compliance with the broad definition may be impractical, at least at present.

A quick review of Y2K-compliance statements issued by computer hardware manufacturers, software producers, and building system suppliers indicates that compliance with the broad definition may be impossible, at least at present.

The following information was available on the manufacturers' web sites at the time this article was written.

IBM
http://www.ibm.com/IBM/year2000/facts/position.html
http://www.software.hosting.ibm.com/year2000/papers/aixy2k.html

IBM considers a product ready, if the product, when used in accordance with its associated documentation, is capable of correctly processing, providing and/or receiving date data within and between the 20th and 21st centuries, provided that all other products (for example, hardware, software and firmware) used with the product, properly exchange accurate date data with it.

Intel
http://support.intel.com/support/year2000/prodstat2.htm

An Intel® product, when used in accordance with its associated documentation, is "Year 2000 Capable" when, upon installation, it accurately stores, displays, processes, provides, and/or receives date data from, into, and between 1999 and 2000, and the twentieth and twenty-first centuries, including leap year calculations, provided that all other technology used in combination with said product properly exchanges date data with it. Intel makes no representation about individual components within the product should they be used independently from the product as a whole.

Microsoft
http://www.microsoft.com/technet/year2k/y2kcomply/y2kcomply.htm

A Year 2000 Compliant product from Microsoft will not produce errors processing date data in connection with the year change from December 31, 1999 to January 1, 2000 when used with accurate date data in accordance with its documentation and the recommendations and exceptions set forth in the Microsoft Year 2000 Product Guide, provided all other products (e.g., other software, firmware and hardware) used with it properly exchange date data with the Microsoft product. A Year 2000 Compliant product from Microsoft will recognize the Year 2000 as a leap year.

Microsoft operating systems all store and manipulate dates in four-digit formats. Additionally, the system clocks have been designed to recognize the year 2000 as a leap year. Within the operating system, the file systems have been designed to handle dates beyond the year 2000 as well. The File Allocation Table (FAT) 16bit and 32bit versions used by MS-DOS, Windows, Windows 95 and Windows NT recognizes dates up to 2108. The File Allocation Table for the Windows CE operating system recognizes dates up to 2999. The Windows NT File System (NTFS) recognizes dates to 29,601.

Carrier
http://128.11.40.108/y2k/compliance.htm

As used in this statement, the term "Y2K Ready" means that the computer software and hardware (including any software, firmware or other hardwired logic embedded within the hardware), by itself or in exchanging data with other software and/or hardware, accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations.

It must be noted that some commercial unitary and applied product applications include control systems supplied by others, such as computer-based load management or energy monitoring systems and third party control components factory-mounted by Carrier at our customers’ request. Carrier is not in a position to determine whether these systems are Y2K ready. We recommend contacting third party suppliers for that information.

Dover
http://www.doverelevator.com/whatsnew/y2k.html

While Dover's elevator controllers are indeed "State of the Art" microprocessor controllers, they are not programmed to be "date aware". Because the Dover Elevator controllers are not aware of the actual date, there will be no problem with the year 2000 date change.

Honeywell
http://www.honeywell.com/year2000/definition.stm

Honeywell defines "Year 2000 Ready" to mean that Honeywell products/software will process dates and times in such a manner that the technical and functional requirements of Honeywell products/software will continue to be materially met without interruption for the years 1999, 2000 and leap year calculations for the Year 2000.

Trane
http://216.46.232.99/corporate/year2000/

American Standard has assembled a Year 2000 compliance team comprised of representatives from its corporate Management Information Systems and internal and external auditing functions, as well as at least one representative from each of its four businesses: Air Conditioning Products, Automotive Products, Plumbing Products and Medical Systems. This compliance team is working with MIS personnel at all company locations, and with American Standard's systems and software vendors, in order to help identify and correct any deficiencies in the company's internal business systems prior to the Year 2000. Although this is a highly technical and time-consuming undertaking, American Standard fully expects to achieve Year 2000 compliance before mid-1999 and is devoting substantial resources to reach that goal.

more information

Similar problems that have already occurred: http://www.year2000.com/archive/similar.html

Year 2000 Home Page:
http://www.year2000.com/cgi-bin/y2k/year2000.cgi

Dangerous Dates for Software Applications
http://www.year2000.com/archive/NFdangers.html

Y2K legislation
http://www.lawpublish.com/s2392-analysis.html.

Federal Government's Gateway for Year 2000 Information Directories
http://www.itpolicy.gsa.gov/mks/yr2000/y2khome.htm

Top of page  

© 1999 Sheldon Wolfe, RA, CSI, CCS, CCCA, swolfe@bwbr.com 
on the web at www.CSI-MSP.org 
January 1999


go to Mpls.-St. Paul Chapter CSI home page home page

Web site design and content Copyright © 1995-2004 Sheldon Wolfe

Material from CSI Chapter newsletters used with permission.