O Servidor MySQL não apresenta nenhum problema com o ano 2000 (Y2K compatível)

O seguinte demonstração simples ilustra que o MySQL Server não tem nenhum problema com datas até depois do ano 2030:

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.00 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),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

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 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

O valor da coluna TIMESTAMP final é zero porque o ano final (2050) excede o TIMESTAMP maximo. O tipo de dados TIMESTAMP, que é usado para armazenar a hora atual, suporta valores na faixa de 19700101000000 a 20300101000000 em máquinas 32 bits (valor com sinal). Em máquinas de 64 bits, TIMESTAMP trata valores até 2106 (valores sem sinal).

O exemplo mostra que os tipos DATE e DATETIME não tem problemas com as datas usadas. Eles irão conseguir trabalhar com datas até o ano 9999.

Embora o MySQL Server seja seguro em relação ao ano 2000, você pode ter problemas se você usá-lo com aplicações que não são seguras com o ano 2000. Por exemplo, muitas aplicações antigas armazenam ou manipulam anos usando valores de 2 digitos (que são ambíguos) em vez de 4 dígitos. Este problema pode ser aumentado por aplicações que usam valores como 00 ou 99 como indicadores de valores ``perdidos''. Infelizmente, estes problemas pode ser difíceis de corrigir, cada um deles pode usar um conjunto diferente de convenções e funções de tratamento de datas.

Assim, apesar do Servidor MySQL não ter problemas com o ano 2000, é de responsabilidade de sua aplicação fornecer datas que não sejam ambíguas. Veja Secção 6.2.2.1, “Assuntos referentes ao ano 2000 (Y2K) e Tipos de Data” para as regras do Servidor MySQL para lidar com entrada de datas ambíguas que contenham valores de ano com 2 dígitos.