MySQLのDATETIMEとTIMESTAMPの違い ― time_zoneで変わる値と2038年の上限

※この記事にはアフィリエイト広告（プロモーション）が含まれます。

DATETIME は書いた日時をそのまま持ち、TIMESTAMP は UTC に直して持ちます。この記事の出力は MySQL 8.4.11（Ubuntu 26.04、time_zone=SYSTEM・system_time_zone=JST）で採りました。

まず見る（結論）

• 2038 年より先の日時を入れる列、タイムゾーンをまたがずに使う列は DATETIME
• アプリやサーバーごとにタイムゾーンが違い、同じ時点を指したい列は TIMESTAMP

time_zone を変えると TIMESTAMP だけ値が変わる

DATETIME 列 dt と TIMESTAMP 列 ts に、time_zone = '+09:00' の接続から同じ '2026-11-08 10:00:00' を入れ、time_zone を変えて読みました。

UNIX_TIMESTAMP() で見ると、ts はどの time_zone でも 1794099600 です。dt は +09:00 で 1794099600、+00:00 で 1794132000 と、読む側のタイムゾーンで解釈されて 9 時間ずれました。WHERE の比較も読む側の time_zone で行われ、+00:00 の接続では WHERE ts = '2026-11-08 01:00:00' で同じ行が返りました。

サーバーの time_zone が SYSTEM のままなら、アプリのドライバーやセッション設定でタイムゾーンを変えない限り差は出ません。接続プールやバッチの片方だけ UTC にしている構成で問題になります。TIMESTAMP 列を使うなら、接続ごとの time_zone をそろえます。

‘Asia/Tokyo’ のような名前は既定では使えない

SET time_zone = 'Asia/Tokyo' は ERROR 1298 (HY000): Unknown or incorrect time zone: 'Asia/Tokyo' でした。mysql.time_zone_name が 0 行で、タイムゾーン表が読み込まれていないためです。'+09:00' の形なら通ります。

オフセット付きのリテラルは DATETIME でも変換される

'2026-11-08 10:00:00+00:00' を +09:00 の接続で入れると、dt も ts も 2026-11-08 19:00:00 になりました。オフセットそのものは残りません。

TIMESTAMP に入る範囲（2038 年問題）

上限・下限は UTC で決まっています。DATETIME 列には 9999-12-31 23:59:59 と 1000-01-01 00:00:00 がそのまま入りました。

SELECT では範囲外の値を返してもエラーになりません。SELECT DATE_ADD(ts, INTERVAL 20 YEAR) は 2046-11-08 10:00:00 を返しますが、同じ式で UPDATE すると ERROR 1292 です。

sql_mode を空にした接続では、2050-01-01 00:00:00 が警告 1264 Out of range value が出るだけでエラーにならず、0000-00-00 00:00:00 が入りました。

DEFAULT CURRENT_TIMESTAMP と ON UPDATE

CREATE TABLE a2 (
  id int PRIMARY KEY, v int,
  created_at timestamp DEFAULT CURRENT_TIMESTAMP,
  updated_at timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  c_dt datetime DEFAULT CURRENT_TIMESTAMP,
  u_dt datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

挿入から 2 秒後に v を書き換えると、updated_at と u_dt がどちらも 2 秒進みました。同じ値で UPDATE したとき（ROW_COUNT() が 0）は、どちらの列も変わりませんでした。

型だけ書いた最初の TIMESTAMP 列に現在時刻が自動で入るのは、explicit_defaults_for_timestamp が OFF の場合の動作です。8.4 の既定は ON（1）です。

DATETIME には式の既定値も書けます。d datetime DEFAULT (CURRENT_DATE + INTERVAL 7 DAY) は、11 月 8 日に INSERT すると 2026-11-15 00:00:00 が入りました。

小数秒は四捨五入される

警告は出ません。切り捨てたいときは sql_mode に TIME_TRUNCATE_FRACTIONAL を足します。足した接続で datetime に .789 を入れると 10:00:00 が入りました。

小数秒付きの列では、既定値も列と同じ精度で書きます。timestamp(3) DEFAULT CURRENT_TIMESTAMP は ERROR 1067 で、DEFAULT CURRENT_TIMESTAMP(3) と書くと通りました。

型を変えるときの注意

TIMESTAMP を DATETIME に変えると、ALTER を実行した接続の time_zone で表示される値が DATETIME に書き込まれます。+09:00 で入れた 10:00:00 の列を +00:00 の接続で ALTER TABLE c MODIFY ts datetime すると、01:00:00 が残りました。+09:00 に戻して読んでも 01:00:00 のままです。ALTER は、アプリが普段使うのと同じ time_zone の接続で実行します。

DATETIME から TIMESTAMP へは、範囲外の行が1行でもあると ERROR 1292 で ALTER 全体が失敗し、表は元のままでした。

関連: MySQLの日付計算 ／ MySQLのDATE_FORMAT ／ PostgreSQLのtimestamptzとは