top
Loading...
1.4.5.2000年兼容性
1.4.5. 2000年兼容性

MySQL服務器本身不存在2000年(Y2K)兼容性問題:

·         MySQL服務器采用了Unix的時間功能,對于TIMESTAMP值,可處理的日期至2037年。對于DATE和DATETIME值,可接受的日期可至9999年。

·         所有的MySQL日期函數均是在1個源文件sql/time.cc中實現的,并經過了恰當編碼以確保2000年安全。

·         在MySQL 3.22和以后的版本中,YEAR列類型能夠在1個字節內保存0年以及1901~2155年,并能使用兩位或四位數字顯示它們。所有的兩位數字年份均被視為介于1970~2069年之間,這意味著,如果你在YEAR列中保存了01,MySQL服務器會將其當作2001年。

通過下面的簡單演示示例,表明MySQL服務器在處理直至9999年的DATEDATETIME值方面不存在問題,在處理2030年以前的TIMESTAMP值方面也不存在問題:

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
 
mysql> CREATE TABLE y2k (date DATE,
    ->                   date_time DATETIME,
    ->                   time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.01 sec)
 
mysql> INSERT INTO y2k VALUES
    -> ('1998-12-31','1998-12-31 23:59:59',19981231235959),
    -> ('1999-01-01','1999-01-01 00:00:00',19990101000000),
    -> ('1999-09-09','1999-09-09 23:59:59',19990909235959),
    -> ('2000-01-01','2000-01-01 00:00:00',20000101000000),
    -> ('2000-02-28','2000-02-28 00:00:00',20000228000000),
    -> ('2000-02-29','2000-02-29 00:00:00',20000229000000),
    -> ('2000-03-01','2000-03-01 00:00:00',20000301000000),
    -> ('2000-12-31','2000-12-31 23:59:59',20001231235959),
    -> ('2001-01-01','2001-01-01 00:00:00',20010101000000),
    -> ('2004-12-31','2004-12-31 23:59:59',20041231235959),
    -> ('2005-01-01','2005-01-01 00:00:00',20050101000000),
    -> ('2030-01-01','2030-01-01 00:00:00',20300101000000),
    -> ('2040-01-01','2040-01-01 00:00:00',20400101000000),
    -> ('9999-12-31','9999-12-31 23:59:59',99991231235959);
Query OK, 14 rows affected (0.01 sec)
Records: 14  Duplicates: 0  Warnings: 2
 
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date       | date_time           | time_stamp     |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2040-01-01 | 2040-01-01 00:00:00 | 00000000000000 |
| 9999-12-31 | 9999-12-31 23:59:59 | 00000000000000 |
+------------+---------------------+----------------+
14 rows in set (0.00 sec)

最后2個TIMESTAMP列的值為0,這是因為年份值(2040,9999)超出了TIMESTAMP的最大范圍。TIMESTAMP數據類型用于保存當前時間,在32位機器上,支持的取值范圍是1970010100000020300101000000(帶符號值)。在64位機器上,TIMESTAMP能處理的值達2106(無符號值)

盡管MySQL服務器本身不存在2000年安全問題,但如果使用了存在Y2K問題的應用程序,也會遇到問題。例如,很多早期的應用程序采用2位數值(兩可性)而不是4位數值來保存和處理年份數據。這類問題可能會被使用“00”或“99”的應用程序合并為“丟失”值指示符。很不幸,這類問題或許很難更正,這是因為不同的應用程序是由不同的程序員編寫的,每位程序員可能使用了不同的慣例集和日期處理函數。

因此,盡管MySQL服務器不存在Y2K問題,但應用程序須提供無歧義的輸入值。關于MySQL服務器在處理含2位年份數值的兩可性日期輸入數據方面的作用,請參見11.3.4節,“Y2K事宜和日期類型” 。

作者:mysql.com
來源:http://dev.mysql.com/doc/refman/5.1/zh/introduction.html
北斗有巢氏 有巢氏北斗