UNIX タイムスタンプの仕組み - エポック秒が時刻表現を統一する理由

エポック秒とは何か

UNIX タイムスタンプ (エポック秒) は、1970 年 1 月 1 日 00:00:00 UTC からの経過秒数で時刻を表現する方式です。この基準時点を「エポック」と呼びます。たとえば 2026 年 5 月 15 日 12:00:00 UTC は、エポックから約 17.8 億秒が経過した時点であり、UNIX タイムスタンプでは 1778846400 と表現されます。

この方式の最大の利点は、タイムゾーンの概念を完全に排除できることです。UNIX タイムスタンプは常に UTC 基準の単一の整数値であり、どの地域で生成されたデータであっても同じ瞬間を同じ数値で表現します。2 つのイベント間の時間差は単純な引き算で求められ、時差やサマータイムの影響を受けません。

なぜ 1970 年が基準なのか

1970 年 1 月 1 日が選ばれた理由は、UNIX オペレーティングシステムの開発時期と密接に関係しています。初期の UNIX (1969〜1971 年に開発) では、当初 1971 年 1 月 1 日を基準とし、1/60 秒単位で時刻を管理していました。しかし 32 ビット整数では約 2.5 年分しか表現できなかったため、単位を秒に変更し、基準を 1970 年に切り上げました。

32 ビット符号付き整数で秒を表現すると、最大値は 2,147,483,647 (約 68 年分) です。1970 年から 68 年後の 2038 年 1 月 19 日 03:14:07 UTC が、32 ビット UNIX タイムスタンプの上限となります。この制約が「2038 年問題」の本質です。

2038 年問題 - 32 ビットの限界

2038 年 1 月 19 日 03:14:07 UTC を過ぎると、32 ビット符号付き整数のタイムスタンプはオーバーフローし、負の値 (-2,147,483,648) に巻き戻ります。これは 1901 年 12 月 13 日として解釈されるため、日付の比較やソートが破綻し、ファイルシステム、データベース、ネットワークプロトコルなど広範なシステムに影響を及ぼします。

現代の 64 ビットシステムではこの問題は解消されています。64 ビット符号付き整数では約 2920 億年分の秒数を表現でき、実用上の上限はありません。しかし、組み込みシステム、レガシーなファイルフォーマット (ext3 のタイムスタンプなど)、古いプロトコルの一部では依然として 32 ビットが使われており、2038 年までに移行を完了する必要があります。

精度のバリエーション - 秒・ミリ秒・マイクロ秒

UNIX タイムスタンプの「秒」は最も基本的な精度ですが、用途に応じてミリ秒 (10 桁→13 桁)、マイクロ秒 (10 桁→16 桁)、ナノ秒 (10 桁→19 桁) の精度が使われます。JavaScript の Date.now() はミリ秒精度 (13 桁) を返し、Python の time.time() は浮動小数点数で秒以下の精度を含みます。

API 設計やデータベーススキーマを決める際は、精度の選択が重要です。金融取引のタイムスタンプにはマイクロ秒以上の精度が求められる一方、ブログ記事の公開日時には秒精度で十分です。異なる精度のタイムスタンプを混在させると、比較演算でバグが発生するため、システム全体で精度を統一する設計が推奨されます。

うるう秒とタイムスタンプの関係

UNIX タイムスタンプは「1 日 = 86,400 秒」を前提としており、うるう秒を考慮しません。うるう秒が挿入される日は実際には 86,401 秒ありますが、UNIX タイムスタンプ上では 23:59:60 という時刻は存在せず、23:59:59 が 2 秒間続くか、翌日の 00:00:00 に巻き戻る実装が一般的です。

Google や Amazon などの大規模システムでは「リープスミア」(leap smear) と呼ばれる手法を採用し、うるう秒を数時間かけて少しずつ分散させることで、タイムスタンプの不連続を回避しています。2022 年に国際度量衡総会 (CGPM) はうるう秒の廃止を決議し、2035 年までに実施される予定です。これにより、将来的にはうるう秒の問題自体が解消されます。