|
Microsoft Year 2000 Readiness Disclosure & Resource Center |
|
|
|
|
Building Year-2000 Compliant Applications with Visual Studio and Windows DNA |
|
2. Executive Summary
Year 2000 compliance permeates every facet of software development. Problems occur when software is designed to store, transmit, pass or calculate date-related information using only the last two digits for the year. Under these circumstances, the year 2000 is interpreted by these programs as 1900, which may result in the failure of the software to perform as expected. Year 2000 compliance problems generally exist in legacy applications, but they are also introduced into new applications because developers take code shortcuts to save space in data records and databases, as well as improperly use date functions and data types. Developers need to be aware of the impact of non-compliance, as well as development techniques to insure compatibility with next millennium.
The Microsoft® Windows DNA architecture represents a comprehensive new framework for integrating client/server and internet software solutions on the Windows platform. Windows DNA is based on the premise of software component integration and interoperability. DNA combines "component based" software development with a "service based" operating system. However, integrated software components and modularity do not protect the developer from introducing Year 2000 compliance problems in their applications. Regardless of the tools used to develop software today, a clear Year 2000 philosophy is needed to avoid spending time reworking an application in future years.
Year 2000 compliance issues are best avoided by strict use of the development tools' date data types and date functions when working with date-related data. Most development tools have built in rules for handling date arithmetic that will avoid Year 2000 compliance problems. Developers should validate that the development tools they are using are Year 2000 compliant and the rules and logic used by the tools for date handling.
Year 2000 Overview
The Year 2000 problem itself is fairly simple: software designed to store date-related information using only the last two digits for the year may not perform as expected when representing dates from the year 2000 and beyond. Since the century is assumed by these programs to always be 19, the year 2000, for example, will be interpreted by these programs as 1900. Non-Year 2000 compliant software will cease to function properly because date-related calculations will not return the expected results. For example, a program that calculates the difference in years between 1978 and 1999 using two-digit date notation would work correctly (99 - 78 = 21 years); whereas a program that calculates the difference in years between 1978 and 2001 using two-digit date notation would not yield the correct result (01 - 78 = -77).
Many applications only deal with current and historical dates. These types of applications, when not Year 2000 compliant, will only exhibit problems when the year 2000 comes upon us. However, many applications in production today are already exhibiting Year 2000 problems. For example, many credit card authorization system had trouble dealing with card expiration dates beyond 1999 (which are generally represented in MM/YY form).
The impact of non-compliance is the failure of the software to perform as expected. In the worst case, total application failure can be expected. At the very least, misrepresented or corrupted data can make its way into the corporate database. This corrupt data may be used as the basis for making key business decisions or, for example, may fail to generate an exception or flag a customer's record when expected.
What exactly is Year 2000 compliance? Microsoft defines a Year 2000 compliant product as one that "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, provided all other products (e.g., other software, firmware and hardware) used with it properly exchange date data with the Microsoft product."
Does this mean that if you are using all Microsoft development tools, or all Year 2000 compliant development tools, that the applications that you develop will automatically be Year 2000 compliant? Not at all. In fact, Microsoft issues a disclaimer with their development tools regarding Year 2000 compliance that states "Compliance refers to the Microsoft product as delivered by Microsoft. The Compliance Statement does not apply to user customizable features or third party add-on features or products, including items such as macros and custom programming and formatting features." What this amounts to is that while the development tool is itself Year 2000 compliant, it is still up to the developer to practice development techniques that insure compliance is maintained in their custom applications.
How did the problem occur?
In order to fully understand the magnitude of the problems presented by the Year 2000, it is helpful to understand historically how the problem occurred.
With mainframe based software development in the '70s, conservation of expensive resources like memory was critical. Developers were able to realize significant memory savings by shortening the year portion of date fields from four characters to just two. Developers today may find this difficult to understand. Considering that each variant data type littered throughout today's typical ASP page consumes over 22 bytes of memory, conserving those additional two bytes seems dubious. But the practice of assuming that the century was the 19th reportedly allowed companies to realize millions of dollars in savings. The need to critically scrutinize every byte of memory used, coupled with the fact that applications were not expected to stand the test of 30 years of time, has in essence created the Year 2000 issue for the information technology industry. Other Year 2000 problems, such as the incorrect calculation of a leap year, or using a "dummy" date such as "9/9/99" as a flag are generally smaller in scope. These problems are related to the lack of insight on the part of the developer, or, in the case of an incorrect leap year calculation, an un-trapped error.
Mainframe-based "legacy" software written decades ago isn't the sole contributor to the problem. Actually, software written today continues to exhibit problems of compatibility with the next millennium. In almost all cases, the problem can be attributed to just two causes:
(1) Developers continue to take shortcuts by representing the year portion of a date with just two digits.
In most parts of society, two digits are used to represent the year portion of a date. The most common way to represent a date in the United States is in the format "mm/dd/yy". It is a custom that people have used in their everyday lives for decades. This custom isn't generally a problem because humans can determine the correct year based on the context in which it is used. Therefore, a four-digit year isn't always necessary.
Think about it: when you sign a contract or write a check, do you write the date's full year, or do you use mm/dd/yy notation? Probably the latter. Unfortunately, computer code is written by humans, and humans have difficulty overcoming their habits.
The general public often scoffs at our industry's Year 2000 problem. The general public, however, will likely face their own personal psychological Year 2000 problems after 1999 when performing everyday tasks like writing checks and computing people's ages. Maybe then they will be more sympathetic to our old code!
Computers cannot make assumptions based on context but instead must apply a single rule to interpret the correct date. The century must be assumed either through the selection of some arbitrary number (19) or by applying a simple rule that determines the century based on the two digit year in question. The 32-bit Microsoft operating systems (with current service packs installed) assume the century is 19 if the two-digit year is 30 or greater. For two-digit years less than 30, the century is assumed to be 20. For software coded today using dates with two-digit years, the computer is essentially guessing the correct date because the developer failed to correctly utilize the tools available to them.
(2) Developers use development tools that don't properly handle date related data, or don't use the date data type correctly.
Many development tools today provide a special data type for handling date-related data. In addition, many provide special functions for performing date conversions, date comparisons, and date math. Using these functions is necessary to prevent inaccuracy, or loss of precision when working with date and time data. Tools that don't provide these services force the developer to substitute a character or string data type, or a less accurate numeric data type. Unfortunately, date math is somewhat complex, and the developer is forced to implement this complexity. For example, developers are required to programmatically deal with leap years and months that contain different numbers of days. In many situations, developers simply ignore these exceptions or deal with them incorrectly.
| 
Features
