Unix タイムスタンプ 0 が表すもの
すべての Unix タイムスタンプは、単一の基準点—1970 年 1 月 1 日 00:00:00 UTC—からの経過時間を数えます。Unix の元の定義では単位は秒なので、タイムスタンプ 0 はちょうど 1970 年 1 月 1 日の UTC 深夜、86400 はちょうど 24 時間後です。現代のシステムはミリ秒・マイクロ秒・ナノ秒も使いますが、基準点は同じです。正の値はエポック以降の瞬間、負の値はそれ以前の瞬間を表します。
なぜ 1970 年 1 月 1 日?
この日付は、1970 年代初頭にベル研究所の Unix 開発者が、Unix 自体の誕生の少し前という実用的な基準点として選びました。通常のシステムのタイムスタンプが正になる程度に早く、初期コンピューターの小さな整数範囲に収まる程度に新しく、頭の中で検証できる程度に単純である必要がありました。Unix が影響力を持つと、言語・OS・データベース・ログ形式・ネットワークプロトコルが同じ起点を受け継ぎました。
- Unix は 1969 年からベル研究所で開発された — エポックはその少し前に設定された
- 1 月 1 日はきれいな暦の境界として選ばれた
- 実装がゼロから始まるカウンターを使ったため、1969 年ではなく 1970 年
- 現代のあらゆる OS・言語・プロトコルがこのエポックを継承した — 競合する標準はない
負のタイムスタンプ:1970 年より前の日付
負の Unix タイムスタンプは、1970 年 1 月 1 日 00:00:00 UTC より前の瞬間を表します。現代の 64 ビットシステムの多くは正しく対応しており、歴史データ・生年月日・アーカイブ記録、そして Unix より早いエポックを持つシステムとの相互運用に役立ちます。古いライブラリやデータベースは負の値を拒否することがあるため、歴史的なデータセットは明示的な互換性チェックに値します。
- -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
- -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
- -2208988800 = January 1, 1900 00:00:00 UTC
- JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'
形式の実用的な上限
Unix エポック自体が上限なのではなく、保存型が上限です。32 ビット符号付き整数に保存されたタイムスタンプは、64 ビット整数・JavaScript の数値・データベースのネイティブ timestamp 型よりはるかに早く破綻します。タイムスタンプの安全性を評価するときは、どの単位かと、どの数値型で保存されるかの両方を問いましょう。
- 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
- JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
- 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
- PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE
他システムのエポック
Unix は計算で使われる唯一のエポックではありません。他のシステムは歴史的・技術的理由から独自の基準点を定義しました。
- GPS エポック:1980 年 1 月 6 日 00:00:00 UTC — GPS 衛星と受信機が使用
- Windows FILETIME:1601 年 1 月 1 日 00:00:00 UTC — 100 ナノ秒間隔
- Apple Cocoa / NSDate:2001 年 1 月 1 日 00:00:00 UTC
- Excel / Lotus 1-2-3:1900 年 1 月 1 日 — Lotus 互換のための意図的なうるう年バグ付き
- FAT ファイルシステム:1980 年 1 月 1 日 00:00:00 ローカル時刻
エポックの秒・ミリ秒・マイクロ秒・ナノ秒
timestamp という語は必ずしも単位を示しません。Unix 秒は OS やバックエンド言語で一般的、Unix ミリ秒は JavaScript やブラウザ API で一般的です。マイクロ秒とナノ秒はデータベース・トレースシステム・高解像度ログに現れます。単位は精度と表示される桁数の両方を決めます。
- Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
- Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
- Microseconds: 1700000000000000 — common in some databases and event pipelines
- Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
- Always document the unit when storing epoch values in APIs, CSV files, and database columns
エポック時間 vs UTC vs ローカル時刻
エポック時間は数です。UTC は基準の瞬間を定義する世界の時間標準です。ローカル時刻は America/New_York や Asia/Tokyo のようなタイムゾーンに基づく表示の選択です。Unix タイムスタンプはユーザーが移動しても変わりません。変わるのは整形された暦日と時刻だけです。
- 同じタイムスタンプでもタイムゾーンが異なれば異なるローカル日付として表示されうる
- UTC 出力はログ・API・サーバー間のデバッグに最適
- ローカル出力はカレンダー・UI・レポートに最適
- タイムゾーンのオフセットは整形時に適用され、Unix タイムスタンプ内には保存されない
エポック時間 FAQ
The Unix epoch (1970-01-01 UTC) was inherited from Multics, the OS that influenced early Unix design. POSIX later standardized the time_t type with explicit semantics that differ from how the original Unix specs described it — and most other platforms count from a different epoch entirely.
- Multics (1969) counted seconds from 1970-01-01 GMT; Unix adopted the same epoch in 1971
- POSIX time_t is defined as a count of seconds since 1970 UTC, explicitly excluding leap seconds (every day is 86,400 ticks)
- POSIX vs Unix terminology: in practice the two are used interchangeably; POSIX is the standardized name
- Other software epochs differ widely:
- Windows FILETIME — 1601-01-01 UTC (Gregorian-cycle start), 100-nanosecond intervals
- .NET DateTime.Ticks — 0001-01-01, 100-nanosecond intervals
- Apple / Core Data — 2001-01-01 UTC (Cocoa reference date), seconds
- NTP — 1900-01-01 UTC, seconds; GPS — 1980-01-06, seconds (no leap seconds)
- Julian Day — noon UT, 4713 BC (proleptic Julian), days
- When importing time data, confirm the epoch before trusting the value as Unix time
Related articles
FAQ
- Is epoch time always in seconds?
- The classic Unix timestamp is seconds since 1970-01-01 00:00:00 UTC, but many systems use milliseconds, microseconds, or nanoseconds with the same epoch.
- Can Unix timestamps represent dates before 1970?
- Yes. Negative timestamps represent dates before the Unix epoch, though older libraries and databases may not support them.
- Does a Unix timestamp include a timezone?
- No. A Unix timestamp represents one instant in UTC. Timezone information is used only when converting that instant into a readable local date.
- What is the maximum Unix timestamp?
- It depends on the storage type, not the epoch. A 32-bit signed integer maxes out at 2,147,483,647 (January 19, 2038), while a 64-bit integer or a JavaScript number reaches hundreds of millions of years. See the Year 2038 problem for the details.