Unix Timestampとは?Epoch Time、Y2K38、コンピューターの時刻処理を解説
Unix timestampは、コンピューターが時刻を扱うためのシンプルな数値表現です。1970年1月1日からの経過秒数として時刻を表し、ログ、API、データベース、プログラミング言語で広く使われます。
目次
Unix Timestampとは?
Unix timestampは、1970年1月1日 00:00:00 UTCから何秒経過したかを表す整数です。Epoch time、Unix time、POSIX timeとも呼ばれます。
例えば0はEpochの開始時刻、1700000000のような10桁の数値は特定のUTC時刻を表します。数値なので比較、保存、ソート、計算が簡単です。
なぜ1970年1月1日なのか
Unixは1969年ごろに開発が始まり、1970年1月1日 00:00:00 UTCが基準点として採用されました。この基準点をUnix Epochと呼びます。特別な天文学的意味があるというより、Unixシステムで扱いやすい実用的な基準日です。
Unix Timestampの仕組み
Unix timestampはUTC基準の経過秒数です。時刻の表示を東京時間、ニューヨーク時間、バンコク時間に変える場合でも、元のtimestamp自体は同じ瞬間を指します。
Unix timestamp: 0
UTC: 1970-01-01T00:00:00Z
Tokyo: 1970-01-01 09:00:00 JSTSecondsとMilliseconds
Unix timestampで最も多い混乱は、秒とミリ秒の取り違えです。JavaScriptのDate.now()はmillisecondsを返しますが、多くのUnixコマンドやAPIはsecondsを使います。
| 単位 | 桁数目安 | 例 | よく使う環境 |
|---|---|---|---|
| Seconds | 10 | 1234567890 | Python、PHP、Ruby、Go、C、Unix CLI、多くのAPI |
| Milliseconds | 13 | 1234567890000 | JavaScript、Java、Dart、一部のREST API |
| Microseconds | 16 | 1234567890000000 | PostgreSQLや高精度ログ |
| Nanoseconds | 19 | 1234567890000000000 | Go、低レベル計測、分散トレース |
TimestampとTimezone
Unix timestampはtimezoneを含みません。常にUTCのある瞬間を表します。timezoneは、その瞬間を人間に表示するときの変換ルールです。保存はUTC、表示はユーザーのtimezone、という設計が一般的です。
有名なUnix Timestamp
| Timestamp | UTC時刻 | 意味 |
|---|---|---|
| 0 | 1970年1月1日 00:00:00 UTC | Unix Epochの開始点 |
| 1000000000 | 2001年9月9日 01:46:40 UTC | Epochから10億秒 |
| 1234567890 | 2009年2月13日 23:31:30 UTC | 開発者が例としてよく使う連番 |
| 2147483647 | 2038年1月19日 03:14:07 UTC | signed 32-bit Unix timeの最大値 |
Year 2038問題 (Y2K38)
32-bit signed integerでUnix timeを秒として保存すると、最大値は2147483647です。これは2038年1月19日 03:14:07 UTCに到達します。その次の秒で値があふれ、古いシステムでは時刻が誤って解釈される可能性があります。
現代の64-bitシステムや多くの言語ランタイムでは対策済みですが、古い組み込み機器、古いOS、レガシーDBでは確認が必要です。
各プログラミング言語での扱い
// JavaScript: milliseconds
Date.now()
Math.floor(Date.now() / 1000)
# Python: seconds
import time
int(time.time())
// Go: seconds and nanoseconds
time.Now().Unix()
time.Now().UnixNano()よく使われる日付形式
| 形式 | 例 | 用途 |
|---|---|---|
| ISO 8601 | 2026-03-18T00:00:00.000Z | API、JSON、database、データ交換 |
| RFC 2822 | Wed, 18 Mar 2026 00:00:00 +0000 | Email headers、HTTP headers |
| RFC 3339 | 2026-03-18T00:00:00Z | APIでよく使われるISO 8601のサブセット |
| Unix seconds | 1773964800 | database、server logs、API |
| Relative | 3 days ago | SNSやコメント欄のユーザー向け表示 |
実際の用途
- ログや監査イベントの時刻記録
- APIレスポンス、JWTの
iat、exp、nbf - データベースの作成日時、更新日時、ソート
- キャッシュの有効期限、rate limit、セッション期限
- メッセージキュー、分散トレース、イベントストリーム
よくあるミス
- secondsとmillisecondsを取り違えて、1970年や未来の日付になる。
- UTCで保存せず、ローカル時刻をそのまま保存する。
- timezone offsetとIANA timezoneを混同する。
- 期限や署名検証でclock skewを考慮しない。
- 32-bit timestampの制限を古いシステムで見落とす。
ベストプラクティス
- 保存と通信ではUTCを使い、表示時にユーザーのtimezoneへ変換する。
- APIでは単位を明記する。例:
created_at_msやドキュメントでseconds指定。 - 人間向けにはISO 8601/RFC 3339、計算やソートにはUnix timestampを使い分ける。
- レガシー環境ではY2K38対応を確認する。
- 日時処理は標準ライブラリや信頼できるライブラリに任せる。
Timestampをすぐに変換
Unix timestampを日付へ、日付をtimestampへ変換し、secondsとmillisecondsの違いも確認できます。
Timestamp Converterを開く