Unixタイムスタンプとは何か、なぜ存在するのか

Unixタイムスタンプはただの大きな数字に見えますが、その数字こそがコンピューターが日時を確実に扱える理由です。

Unix時間は決められた起点からの経過秒数

Unix時間は、1970年1月1日午前0時(UTC)、通称「エポック」からの経過秒数を数えたものです。歴史上のどの瞬間も、読む人がどのタイムゾーンにいようと、必ずひとつの整数に対応します。

秒とミリ秒の違いは典型的なバグの原因

多くのシステムレベルのツールは秒単位を使う一方、多くのウェブAPIやJavaScriptは ミリ秒単位を使います。同じ瞬間の値が、どちらの前提を想定しているシステムかによって、ちょうど1,000倍違って見えることがあり、実務でもっともよくあるタイムスタンプ関連のバグのひとつです。

生のタイムスタンプ自体にはタイムゾーンの情報がない

数字そのものにはタイムゾーンの概念が一切含まれておらず、その数字を人間が読めるカレンダー日付に変換する段階で初めてタイムゾーンが関わってきます。これこそが、異なる地域間で時刻を一貫して保存・比較する際にタイムスタンプが便利な理由です。

表示にはISO 8601形式がよく対になって使われる

生のタイムスタンプは、2026-09-21T00:00:00Zのような人間が読みやすいISO 8601形式との間で相互に変換されることがよくあります。ISO 8601はコンピューターが解析しやすく、かつ人間にも読みやすい形式だからです。

1970年より前の日付は負の数で表される

エポック以前の瞬間は負の整数で表され、この形式自体は未来の遠い日付まで問題なく拡張できますが、一部の古いシステムには技術的な上限が設けられています。

2038年問題

Unix時間を符号付き32ビット整数で保存しているシステムは、2038年1月19日にオーバーフローを起こします。これはY2K問題になぞらえて語られることもある既知の制約で、32ビットで時刻を保存し続けている古いソフトウェアや一部の組み込み・レガシーシステムに特に影響します。

なぜソフトウェアはカレンダー日付ではなく巨大な数字を使うのか

時刻を構造化された日付オブジェクトではなく単一の整数として保存すると、2つの瞬間の比較、イベントの一覧の並べ替え、経過時間の計算(「この2つのイベントの間に何秒経過したか」など)が、カレンダーを意識した複雑な計算ではなく単純な四則演算で済みます。また、人間が実際にその値を読む必要が生じる瞬間まで、タイムゾーンやカレンダー形式のあいまいさを完全に回避できます。

実際にどこで生のUnixタイムスタンプに出会うか

ログファイル、データベースのレコード、APIのレスポンス、URLのパラメータ、クッキーの有効期限などは、整形された日付文字列ではなく、コンパクトで曖昧さがなく比較しやすいという理由から、生のUnix数値として時刻を保存していることがよくあります。この生の数値を読みやすい形式に変換する作業は、ソフトウェア開発でもっとも日常的な作業のひとつです。

よくある質問

なぜタイムスタンプの値がちょうど1,000倍ずれて見えるのか?

ほとんどの場合、秒とミリ秒の取り違えが原因です。受け取る側のシステムがどちらの形式を想定しているかに応じて、値を1,000倍するか1,000で割るかしてみてください。

タイムゾーンが違うとUnixタイムスタンプの値も変わるのか?

いいえ。同じ瞬間であれば、世界のどこにいても数字そのものは同一です。変わるのは、変換の際にどのタイムゾーンが適用されるかによって表示される、人間が読める日時の文字列だけです。