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事宜和日期类型”