ASSET Y2K
Year 2000 Compliance
Background and Explanation of Y2K issues
ASSET and Y2K Compliance
Conclusion
Background and Explanation of Y2K issues
(Back To Top)
The Y2K problem results from an industry-wide practice of representing years with only two digits instead of four (97 instead of 1997). From the 1960's to the 1980s, using two digits was standard practice to save disk and memory space because these resources were relatively expensive. To compound the problem, many standards and programming guides promoted two-digit year formats, as well as some common specifications, such as ANSI and DOD.
These two-digit year representations can cause application problems during the transition to the year 2000 if the system interprets the year 00 as 1900 or interprets any two-digit year (01, 02, and so forth) as a 1900s date. In versions of Asset prior to version 3, this would have meant that notes and other date related data would have been wrongly interpreted e.g.
- Leap Year Accountability: a failure to recognize that the Year 2000 is divisible by 400 and, therefore, meets the criteria for a leap year with a February 29. Neither 1900 nor 2100 contains a February 29.
- Incorrect Data Calculations: arithmetic operations (such as sorting) using dates, for example 00 > 99 returning "false" but 2000 > 1999 returning "true." Similarly, 2000-1998 should yield 2 rather than 00-98 = -98.
- Hard coded default to century value of "19": two-digit year values that are interpreted as "19," meaning that when "00" is entered where the Year 2000 is intended would result in a value of 1900.
ASSET Software Products and Y2K Compliance
(Back To Top)
The following section describes Y2K compliance for ASSET Recruitment Software products in relation to data stored in the Date format.
ASSET Version 3 has been tested for Year 2000 compliance and the tests have determined that ASSET does not present any Year 2000 limitations. All dates are now stored in a format which maintains the year value in its four digit value. This date format is the standard one used by Pervasive Software in its Pervasive.SQL product and is recognised by ODBC drivers
ASSET continues to permit the entry of a two digit year on input. This makes use of a system-wide user-settable parameter (default 20) which may be shifted forward as required. The default of 20 means that year values 00 thru 20 are interpreted as 2000 thru 2020 whereas 21 thru 99 are taken to mean 19xx. The entry of 2 digit year values is offered for convenience and speed of data entry. Year values may be entered in the full four digit form if preferred.
Btrieve
Some single-user and workgroup versions of Asset still use Btrieve v6.15 which, though no longer supported by its authors (Pervasive Software), has been tested for Year 2000 compliance. These tests have determined that Btrieve v6.15 does not present any Year 2000 limitations. Btrieve v6.15 uses the same date format as described above. We recommend that users of Btrieve 6.15 upgrade to Pervasive.SQL 2000 in order to get the benefits of support as well as greater productivity. Existing users can verify their current version of Pervasive/Btrieve by clicking Help->Current User Information.
Pervasive discontinued marketing and support of Btrieve v6.10 and other prior versions of Btrieve (including, but not limited to, v5.x) over two years ago. Because these products are not currently offered or supported by Pervasive, they were not included in their Y2K compliance testing, and therefore we do not warrant their Y2K compliance. There are no users of Asset on these old versions of Btrieve.
ODBC
There are no Year 2000 limitations for ODBC Interface v2.x which is the version of ODBC in use with Asset Version 3.
Conclusion
(Back To Top)
Y2K compliance has been a significant part of the development of Asset. Asset Version 3 has been re-engineered and tested for dates after 31st December 1999. Existing users should verify that their current version is greater than 3.0 by clicking Help->About.