【正文】 est version that has been or will be fully tested to be pliant pletion date, the legal date range supported by the product, and the rules for how the century is inferred for a 2digit year. Some of the product data is simply not applicable, as in the case of jConnect, because that product does not manipulate the date fields but passes them unchanged among its attached clients and servers. Other product data is unavailable, because, as in the case of Infopump, the product is sold and supported by another software pany who is responsible for its Year 2000 pliance. The peculiar date 1753 as the first legitimate century of the range es about because of the adoption of the Gregorian calendar at about that time which eliminated several weeks in the month of October that year. Prior to that date, some date functions (like the days of the week) are nondeterministic. For most business purposes, this limitation is not a handicap, and has no bearing on the year 2000 issue. Although it supports the 4digit year requirements of Year 2000 pliance, the DOS operating system from Microsoft contains a limitation that limits the date range to less than that supported by our products. Microsoft DOS only supports dates up to 2099/12/31. The Microsoft DOS FAT file system has a restriction on file date stamps with respect to the range of years it supports. Thus the DOS version of our tools do not operate correctly past 12/31/2099. Products may differ in their legal date range because of the platforms they run on. In the case of Power++ (Optima ++) for example, runtime library time functions are based on a 32bit unsigned time_t value whose minimum value represents 1970/01/01 00:00:00 GMT and whose maximum value represents 2106/02/06 06:28:15 GMT. Other products running on UNIX have very large legal date ranges. Known pliance issues are also maintained in the matrix. These issues may have been raised by internal test or by customer reports. As of 6/30/97, only a handful of products are known to have minor problems with handling Year 2000 criteria. For example, the SQL Server error log contains 2digit dates that might cause errors for a program scanning the error log that itself was not Year 2000 pliant. All of these known problems are either fixed in the next maintenance release of the product, or in the next functional release. 4. Compliance Check List Sybase has developed criteria for all engineering organizations to use in developing tests for pliance with Year 2000 standards. As of 7/15/98, the current releases of almost all products currently available from Sybase will be tested for fulfillment of the stringent pliance criteria. Sybase tests for Year 2000 pliance are based on the following posite criteria:5. General IntegrityA. Does the product provide a function to obtain the system date on the host or through a time service? B. Does the product return the correct value for system date for high risk dates: 9/9/9912/31/991/1/002/29/00C. Does the product return the correct value for system date after the system date rolls over on highrisk dates: 19981231 1999010119991231 2000010120000228 2000022920000229 20000301 6. Date Integrity A. Does the product support a data type for date values in the range 19000101 to 20501231? B. Do the product routines treat 2000 as a leap year and 1900 as a nonleap year? C. Does the date arithmetic correctly calculate differences between dates, add dates and durations, and pute date of week across centuries? D. Does the product correctly pare dates across centuries? E. Does a key index that includes a date field produce correct sequence across dates in 19xx and 20xx? F. Does the product retrieve dates accurately for values in the range 19000101 to 20501231? G. Does the product convert date values from one representation to another (for example, YMD to Julian to baseandoffset internal)? H. Is the date function free of special values? (.: a year value of 99 or 00 meaning end of file) I. If the product uses sort/merge utilities to order file contents on date fields or uses indexed file structures keyed on date fields, is the order correct for all values of date in the range 19000101 to 20501231? 7. Explicit Century A. Does date data type permit setting explicit values for century, stored in an 8digit field with a 4digit year? B. Do retrieval functions permit formatting dates with explicit century? 8. Implicit CenturyA. Does date data type provide for data types without explicit century? B. If the value for century is not explicitly provided, is the century value derived consistently from the value of the date provided? 9. Conclusion The ability of Sybase Products to perform in the manner described above is, of course, dependent upon the receipt of correctly processed and transmitted data from and by all nonSybase supplied products (such as hardware, software and firmware) that the Customer uses in connection with the Sybase Products. Nothing contained in this white paper or the acpanying matrix is intended to modify rights and obligations under any agreement between the parties or to guarantee that any software is errorfree. Correction of any bugs regarding Year 2000 functionality may require application of the minimum EBFs indicated in the product matrix. We remend that all customers test their puter applications for the pliance described above by supplying them with year 2000 dates as described, and run test versions of their application on a machine on which the date has been changed to year 2000. Only through running a set of such acceptance tests can puter users assure themselves that their applications are free of the Millennium Bug. Without this vigilance, users may risk their entire businesses through applications that will not act correctly following midnight on December 31, 1999.