データ型

日付型・時刻型ひづけがた・じこくがた

DATETIMESTAMPDATETIMEタイムゾーンデータベース日時

日付型・時刻型について教えて

簡単に言うとこんな感じ！

日付型・時刻型は「カレンダーと時計をデータベースに持ち込んだ引き出し」だよ！「2026年4月11日の午前10時30分」みたいな情報をそのまま保存できるから、「先月の売上」「この1週間の注文数」みたいな期間での検索や集計がぱっとできるんだ！

日付型・時刻型とは

日付型・時刻型 とは、データベースやプログラミング言語において「日付・時刻に関する情報を格納するためのデータ型」です。注文日時・更新日時・予約日・生年月日など、時間に関わるほぼあらゆる業務データに使われます。

テキスト型に "2026-04-11" という文字列として日付を保存することも技術的には可能ですが、日付型を使うと 日付の大小比較・期間での絞り込み・経過日数の計算 などが簡単かつ正確にできます。たとえば「30日以上経過した未対応チケットを抽出」といった処理は、専用の日付型なしでは非常に複雑なSQL文が必要になります。

また、タイムゾーン（時差） の扱いも重要な設計ポイントです。グローバルなサービスや、クラウドサービスとの連携では「サーバーの時刻がUTC（協定世界時）なのに日本時間で表示したい」という問題が頻発します。タイムゾーンを正しく扱える型を選ぶことが、障害を未然に防ぐカギになります。

主な日付・時刻型の種類

代表的なRDBMS（MySQL/PostgreSQL）での型一覧です。

型名	格納できる情報	範囲の目安	主な用途
`DATE`	年・月・日のみ	1000-01-01〜9999-12-31	生年月日・納期・契約開始日
`TIME`	時・分・秒（・マイクロ秒）	-838:59:59〜838:59:59	営業時間・所要時間
`DATETIME`	日付＋時刻（タイムゾーンなし）	1000-01-01〜9999-12-31	作成日時・更新日時（ローカル用途）
`TIMESTAMP`	日付＋時刻（タイムゾーン考慮）	1970-01-01〜2038-01-19	ログ記録・グローバルサービスの時刻
`YEAR`	年のみ	1901〜2155	製造年・入学年度など
`INTERVAL`（PG）	期間（〜日・〜時間など）	—	経過時間・所要時間の計算

DATETIME と TIMESTAMP の違い（重要）

DATETIME と TIMESTAMP は見た目が似ていますが、タイムゾーンの扱い方が根本的に違います。

DATETIME:
  保存したまま返す。「日本で2026-04-11 10:00」→ 常にそのまま返す
  タイムゾーンが変わっても値は変わらない

TIMESTAMP:
  UTC（世界標準時）に変換して保存し、取り出し時にDBのタイムゾーン設定で変換
  DBサーバーをアメリカに移すと表示が変わる

歴史と背景

1970年代 — Unix時間（Unixエポック）の概念が生まれる。1970年1月1日00:00:00 UTCを起点とした秒数で時刻を管理する方式で、現在も多くのシステムで使われる
1987年 — SQL標準（SQL-86/SQL-89）に DATE・TIME・TIMESTAMP が定義される
1999年 — SQL:1999 でタイムゾーンを含む TIMESTAMP WITH TIME ZONE が追加
2000年 — Y2K問題（西暦2000年問題）が世界中を揺るがす。2桁で年を管理していたシステムで障害が多発し、日付型の設計の重要性が広く認識された
2038年問題 — TIMESTAMP 型（32ビット整数でUnix時間を表現）は2038年1月19日に上限に達する。現代のDBMSは対策済みだが、古いシステムには注意が必要

タイムゾーンと日付計算の落とし穴

よくある日付関連のトラブル

うるう年・月末の扱い誤り — 2026-02-31 のような存在しない日付を文字列で保存してしまうミス。日付型なら自動的にエラーになる
サマータイムのバグ — 海外のユーザーを持つシステムで DATETIME を使うと、サマータイム切り替え時に1時間ずれるケースがある
2038年問題 — 32ビットの TIMESTAMP は2038年1月19日を超えられない。将来性を考えて DATETIME や64ビット対応の型を選ぶことも重要

規格・RFC番号	内容
ISO 8601	日付・時刻の国際標準表記。`YYYY-MM-DD`・`T`区切りの時刻形式を定める
RFC 3339	インターネット上での日時フォーマット標準。ISO 8601のサブセット
ISO/IEC 9075	SQL標準。`DATE`・`TIME`・`TIMESTAMP` 型の仕様を定義