【正文】 tem 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.A1　Sybase產(chǎn)品合格印證本文主要為解決“兩千年問題”。 主要闡述“千年蟲”問題，該問題的業(yè)界標(biāo)準(zhǔn)，以及Sybase產(chǎn)品與此業(yè)界標(biāo)準(zhǔn)的關(guān)系?！『喗樵S多機構(gòu)已努力給其所謂的“符合2000年要求”或更籠統(tǒng)的“符合世紀(jì)要求”下定義，并要求它們的經(jīng)銷商們確認(rèn)各自的產(chǎn)品都真正“符合要求”。這么做的目的是為了保證它們投資用于新應(yīng)用的數(shù)據(jù)庫、中間件和工具不會受到“千年蟲”的影響。這份白皮書簡要地討論了該問題的實質(zhì)、符合2000年要求的定義，以及Sybase產(chǎn)品是如何符合2000年要求的。１．常見的2000年問題 由于應(yīng)用軟件中處理日期的方式不同，以致一些應(yīng)用軟件會碰到各種各樣的有關(guān)日期的系統(tǒng)性問題。常見的問題包括： 。例如，一些應(yīng)用可能用兩位數(shù)的年份數(shù)據(jù)段的“00”或者月/日/年數(shù)據(jù)段的“9999”來表示未知或尚未確定的日期。在沒有明確的世紀(jì)信息的情況下，這些標(biāo)記無法與每個世紀(jì)中合法的日期如9/9/99區(qū)分開來。 ，因此2000年是個有2月29日的閏年，而1900年和2100年都沒有2月29日。 。例如表達式0099的返回值是“假”，但20001999的返回值是“真”。同樣，20001998的得數(shù)應(yīng)該為2，而不是0098=98。 ，幾乎是19世紀(jì)，因此，當(dāng)輸入00以表示2000年時，計算機中存儲的很可能只是1900年。 客戶對標(biāo)準(zhǔn)的要求是希望確保他們的應(yīng)用軟件的基礎(chǔ)軟件、操作系統(tǒng)、數(shù)據(jù)庫、中間件和工具產(chǎn)品全都沒有以上問題，這樣它們正確編寫的應(yīng)用就不會因為其基礎(chǔ)系統(tǒng)的錯誤而出現(xiàn)問題。2．2000年標(biāo)準(zhǔn)現(xiàn)在尚沒有用于2000年問題的通用軟件標(biāo)準(zhǔn)，因此許多公司制訂了自己的一組要求并希望Sybase公司的產(chǎn)品予以符合它們唯一的標(biāo)準(zhǔn)?，F(xiàn)在可以查到的最完整的2000年要求標(biāo)準(zhǔn)匯總是GTE Government Systems公司的《Millennium 2000 Program Document PA96014 Revised 19660619》。由于各種要求非常繁雜，我們將其中的一部分定義要點做了如下匯總，包括英國標(biāo)準(zhǔn)協(xié)會（British Standards Institute）DISC PD20001標(biāo)準(zhǔn)：所有客戶都以這種或那種的方式對“符合世紀(jì)要求”提出了如下四條判斷標(biāo)準(zhǔn)： ：表示當(dāng)前日期的任何值都不會中斷正常的系統(tǒng)運作：在詢問當(dāng)前日期時，系統(tǒng)總是返回包含世紀(jì)值的正確