 |
 |
 |
 |
 |
 |
 |
|||||
|
|
|
|
|
|
|
|||||
|
Overview: What is year 2000 compliance? The recording of dates is of key importance in human history. Virtually any important document or piece of information has an associated date. Driver licenses have birth dates and expiration dates. Legal contracts have enactment dates. The importance of dates not only exists in the world of written paper documents, but also electronic information stored in computer systems. With legal paper documents, dates are fully described by stating a day, month, and a year. In legal documents, the year portion of the date is written out with four digits. However, in casual writing the year portion of dates is commonly abbreviated to include only the last two digits: Legal Date: September 1, 1997 Casual Date: 9/1/97 Most people have no problem identifying both of the above dates as September 1, 1997. However, imagine that the current date is now December 2, 2097, over 100 years in the future. In the context of this future date, a person would interpret the casual date of 9/1/97 as the legal date of September 1, 2097. Here is the core of the year 2000 problem. If the year portion of a date is only represented in two digits, the dates become ambiguous if the range of dates spans 100 years (the number of years a 2 digit date can represent). Since computers have only been in heavy use for about 30 years, why are we running into this 100-year problem now? It is because the 100-year problem will occur one year before every new century, which is the year 2000 for those of us living in the 20th century. Just imagine a computer database that stores health insurance policy information. One key piece of data for every policy is the birth date of the policy owner. If the database stored dates with a 2 digit year, what would be the legal representation of the following date? 2/1/01 The above date could be a newborn on February 1, 2001, or a long-lived 100-year-old individual born on February 1, 1901. The example above is just one of thousands of possible ambiguous scenarios that exist with the use of 2 digit years. Many computer applications and databases developed in the 70s, 80s, and even the 90s store dates using a 2 digit year format. The SolutionsIQ products division has had many requests for information about year 2000 compliance with the CONNX product. This document describes how CONNX is year 2000 compliant, and also additional features that help in providing year 2000 compliance to applications and database that do not store the full 4 digit year, making it vulnerable to year 2000 problems.
The ODBC Specification is 100% year 2000 compliant. This means that all dates in ODBC store the full 4 digit year, making it possible to discern the year 2020 from the year 1920. Dates in ODBC are stored in C structures, as shown below: /* SQL portable types for C */ /* transfer types for DATE, TIMESTAMP */ typedef struct tagDATE_STRUCT { SWORD year;UWORD month; UWORD day; } DATE_STRUCT; typedef struct tagTIMESTAMP_STRUCT { SWORD year;UWORD month; UWORD day; UWORD hour; UWORD minute; UWORD second; UDWORD fraction; } TIMESTAMP_STRUCT; Notice that the year portion of both dates is stored in a SWORD, which is a signed word. This means that ODBC dates can have a range from the year 0 to the year 32767. This provides a buffer of 30,767 years before we run into a "Year 32767 Compliance" problem. ODBC dates will be valid for the next 30 millenium. As a result, the entire CONNX product is also 100% year 2000 compliant, since it is based on the ODBC specification.
CONNX provides data connectivity to enterprise data, even databases that were designed to use a 2 digit year. For every date data type that CONNX supports that only includes a 2 digit year, CONNX provides an alternate data type that is year 2000 compliant. This is accomplished through a technology called "date windowing". Date windowing is a method of using a 2 digit year to represent dates that span a single century. This is accomplished splitting the 100-year range of a 2 digit year, and assigning a portion of the years to one century, and the remaining years to the following century. Consider the following example: Casual Date: 3/5/42 In the current century, we would consider this as a legal date of March 5th, 1942. However, using a date window range from 1941 to 2040, the above date would have a legal date of March 5th, 2040. A date window range from 1941 to 2040 means that any 2 digit year greater than 40 will be considered in the 20th century, and any 2 digit year less than or equal to 40 will be considered in the 21st century. Consider the following examples: Casual Date: 3/5/32 With Year 2000 Date Windowing: March 5th, 2032 Without Year 2000 Date Windowing March 5th, 1932 Casual Date: 3/5/82 With Year 2000 Date Windowing: March 5th, 1982 Without Year 2000 Date Windowing March 5th, 1982 Obviously, date windowing is NOT a permanent solution for applications that only store a 2 digit year. Eventually, those applications and databases will need to be modified so that the year contains the full 4 digits. However, date windowing will provide additional time and breathing room for companies to make the year 2000 plunge – in the 21st century.
[Home][Products/Services][User Stories][Support][News/Events][Contact Us] |
