MySQL サーバ
自体は、西暦 2000
年(Y2K)対応に関しては何の問題もありません。
MySQL
サーバ
では、TIMESTAMP
値については日付を 2037
年に処理する Unix
時間関数を使用する。DATE
値および DATETIME
値については、9999
年までの日付が使用可能である。
MySQL
日付関数すべてが 1
つのファイル sql/time.cc
に格納され、西暦 2000
年に対応するように非常に慎重にコード化されている。
MySQL
バージョン 3.22
以降では、YEAR
型のカラムに
0
年および 1901
年から 2155
年までの年を 1
バイトで格納し、2 桁または 4
桁で表示することができる。2
桁の年はすべて、1970
年から
2069
年までの範囲にあると見なされる。つまり、YEAR
型のカラムに 01
を格納した場合、MySQL
サーバ
では 2001
として処理される。
次の簡単な例で、MySQL サーバ
に
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)
TIMESTAMP
型のカラムの最後の値がゼロになっているのは、最後の年(2050
)が
TIMESTAMP
の上限を超えているためです。TIMESTAMP
データ型は現在の時刻を格納するために使用され、32
ビットマシンでは 19700101000000
から 20300101000000
までの値(符号付きの値)をサポートします。64
ビットマシンでは、2106
までの値(符号なしの値)を処理します。
この例は、DATE
および
DATETIME
データ型にも日付の使用に関する問題がないことを示しています。これらのデータ型では、9999
年までの日付が処理されます。
MySQL サーバ
自体は Y2K
に対応していますが、Y2K
に対応していないアプリケーションとともに使用すると、問題が発生することがあります。たとえば、多くの古いアプリケーションでは、4
桁の値ではなく、あいまいな 2
桁の値を使用して年の格納や処理が行われます。この問題は、値が
``ない'' ことを示す場合に 00
や
99
などの値を使用するアプリケーションでは、さらに複雑になる可能性があります。それぞれのアプリケーションはさまざまなプログラマによって記述されており、プログラマごとに異なる規則や日付処理関数を使用している可能性があるので、これらの問題を修正するのは困難な場合があります。
そのため、MySQL サーバ
に Y2K
問題がなくても、アプリケーションとしてあいまいでない情報を提供することが必要です。年を表す
2
桁の値を含むあいまいな日付入力データの処理に関する
MySQL
サーバ
のルールについては、項6.2.2.1. 「西暦 2000 年問題と日付型」
を参照してください。
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.