Unix タイムスタンプを扱う: エポック時間をシンプルに

API 応答やデータベースの行を開くと、日付が 1751760000 のような素の数値として保存されているのをよく見ます。それが Unix タイムスタンプ で、膨大な量のソフトウェアがこうして時間を追跡します。このガイドはその数値が何を意味するのか、なぜコンピューターがこう時間を数えるのか、そして落とし穴 — 秒 vs. ミリ秒、タイムゾーン、2038 年問題 — を説明します。

Unix タイムスタンプとは何か

Unix タイムスタンプは、エポック（epoch） と呼ばれる固定の瞬間 — 1970 年 1 月 1 日 00:00:00 UTC — 以降に経過した 秒 数です。だから 0 はエポックそのもの、60 はその 1 分後、1751760000 は 2025 年のある瞬間です。ただの秒の積算です。

なぜ 1970 年から秒を数えるのか?

時間を単一の整数として表すのはコンピューターに極めて便利です。2 つの瞬間を比べるのは 2 つの数を比べることになり、その差を求めるのは引き算、イベントを並べ替えるのは整数を並べ替えるだけ — 暦・月・うるう年・タイムゾーンを考える必要はありません。1970 年という起点は、Unix オペレーティングシステムの初期の歴史的な選択がそのまま定着したものです。

秒 vs. ミリ秒の罠

ほぼ誰もが少なくとも一度ははまる間違いです。Unix タイムスタンプは古典的に 秒 単位ですが、多くのシステム — 特に JavaScript — は ミリ秒（1000 分の 1 秒）を使います。両者は 1000 倍違います:

秒:      1751760000
ミリ秒:  1751760000000

ミリ秒を期待する所に秒の値を入れると日付が 1970 年に落ち、逆にすると数万年先へ行きます。素早い確認: 現在のタイムスタンプは 秒 なら 10 桁、ミリ秒 なら 13 桁です。変換した日付がばかげて見えるときは、ほぼ必ずこれが理由です。

タイムゾーンと UTC

Unix タイムスタンプの重要な強み: 数値そのものが 常に UTC です。それは地球上の誰にとっても同じ、1 つの正確な瞬間を表します。タイムスタンプ 1751760000 は単一の瞬間で、それがロンドンで午後 4 時に見えようとニューヨークで午前 11 時に見えようと、それは最後に適用される純粋な表示上の選択にすぎません。時間を UTC タイムスタンプで保存し、表示するときだけローカル時刻に変換すれば、タイムゾーンのバグ一群をまるごと避けられます。同じ瞬間を異なる地域で見るには、タイムゾーン変換ツール がうってつけです。

人が読む日付との相互変換

両方向が絶えず必要になります — ログをデバッグするためにタイムスタンプを読める日付に、API を照会するために日付をタイムスタンプに。当サイトの Unix タイムスタンプ変換ツール は両方を即座に行い、結果をあなたのローカル時刻と UTC で表示します。代わりに 2 つの日付の差を測るなら、日付差計算ツール が直接扱います。

2038 年問題

古いシステムはタイムスタンプを 符号付き 32 ビット整数 として保存しますが、これは 2,147,483,647 までしか数えられません。その上限は 2038 年 1 月 19 日 03:14:07 UTC に達し — 1 秒後にカウンターがあふれて負の数に折り返し、日付を 1901 年へ投げ返します。Y2K と同じ種類のバグです。解決策はすでに広く普及しています: 64 ビット整数を使えば、上限は約 2920 億年先へ押しやられます。ほとんどの現代ソフトは問題ありませんが、レガシーシステムを触るときは知っておく価値があります。

クイックリファレンス

• Unix タイムスタンプ = 1970 年 1 月 1 日 UTC 以降の秒。
• 10 桁 = 秒; 13 桁 = ミリ秒。
• 値は常に UTC — タイムゾーンは表示するときだけ適用。
• 32 ビット保存は 2038 年に壊れる; 64 ビットは壊れない。