Unix タイムスタンプを日付に変換
Unix タイムスタンプを読みやすい日付と時刻に変換します — または任意の日付を Unix タイムスタンプに変換します。秒とミリ秒に対応しています。
Unix タイムスタンプとは？
Unix タイムスタンプは、Unix time または POSIX time とも呼ばれ、1970-01-01 00:00:00 UTC からの経過秒数です。この基準点を Unix エポックと呼びます。単一の整数で時点を表現できるため、保存、比較、計算が簡単になり、コンピュータ業界で広く使われている標準です。
JavaScript は内部的にミリ秒で動作するため、Date.now() は Unix タイムスタンプに 1000 を掛けた値を返します。多くの API、データベース、バックエンド システムは秒を使用します。このツールはどちらの形式でも受け入れ、入力した数値の大きさに基づいて秒またはミリ秒を自動で判別します。
注目すべき Unix タイムスタンプ
| タイムスタンプ | 日時 (UTC) | 説明 |
|---|---|---|
0 | 1970-01-01 00:00:00 | Unix エポック |
1,000,000,000 | 2001-09-09 01:46:40 | 10 億秒 |
2,000,000,000 | 2033-05-18 03:33:20 | 20 億秒 |
2,147,483,647 | 2038-01-19 03:14:07 | 2038 年問題（32 ビット最大値） |
なぜ 1970 年なのか？
Unix エポックが 1970 年 1 月 1 日に設定されたのは、慣例と実用性の両面からの選択です。Unix は 1960 年代後半から 1970 年代初頭にかけてベル研究所で開発されました。開発者は時刻表現の起点として、最近の区切りの良い日付が必要でした。1970 年 1 月 1 日は実用的に十分に最近で、特別な技術的意義はなく、単に都合の良い基準点だったのです。
他のシステムでは異なるエポックが使われています。Windows FILETIME のエポックは 1601 年 1 月 1 日、GPS タイムは 1980 年 1 月 6 日、NTP エポックは 1900 年 1 月 1 日です。システム間での変換時には、各システムのエポックを理解することが重要です。
秒とミリ秒
元来の Unix タイムスタンプは秒単位です。ほとんどのサーバーサイド言語とシステム（Unix シェル、Python の time.time()、PHP の time()、ほとんどのデータベース）は秒を使用しています。JavaScript の Date.now() と new Date().getTime() はミリ秒を返します。このズレは、JavaScript フロントエンドがバックエンド API と通信するときの一般的なバグの原因です。
現在の Unix タイムスタンプ（秒単位）は 10 桁の数値です（2023 年時点で約 1,700,000,000）。ミリ秒単位のタイムスタンプは 13 桁です。計算機は入力した数値の桁数に基づいて形式を判別し、適切に変換します。
2038 年問題
Unix タイムスタンプを符号付き 32 ビット整数で保存するシステムでは、エポックから 2,147,483,647 秒後、つまり 2038 年 1 月 19 日 03:14:07 UTC までの日時しか表現できません。その時点の後、32 ビット符号付き整数はオーバーフローして大きな負の数になり、1901 年の日時を表します。
これは「Y2K38」問題や Unix ミレニアム バグと呼ばれることもあります。現代の 64 ビット システムは影響を受けません。64 ビット符号付き整数は約 292 億年分のタイムスタンプを表現できます。しかし、組み込みシステム、レガシー データベース、古い 32 ビット ソフトウェアは依然として脆弱である可能性があります。通信、銀行、産業制御システムなど多くの業界では、対応のための移行作業が進行中です。
現在の Unix タイムスタンプを取得する
| 言語 / 環境 | コマンド |
|---|---|
| JavaScript | Math.floor(Date.now() / 1000) |
| Python | import time; int(time.time()) |
| PHP | time() |
| Bash | date +%s |
| SQL (PostgreSQL) | EXTRACT(EPOCH FROM NOW())::int |
| SQL (MySQL) | UNIX_TIMESTAMP() |
| Go | time.Now().Unix() |
| Rust | SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() |
実践的な活用
API 開発: REST API では一般的に created_at、updated_at、トークン有効期限フィールドに Unix タイムスタンプを使用します。タイムスタンプはタイムゾーンに依存せず明確です。フォーマット済みの日付文字列と異なり、ロケールやフォーマット規約に左右されません。
トークン有効期限: JWT（JSON Web Token）は exp（有効期限）と iat（発行時刻）クレームに Unix タイムスタンプを使用します。現在のタイムスタンプが exp 値を超えるとトークンは有効期限切れになります。有効期限の計算（「このトークンは 24 時間後に期限切れにしたい」など）では、現在のタイムスタンプに 86,400 秒を足します。
キャッシュ TTL: キャッシュの有効期限は Unix タイムスタンプまたは現在からの秒数で設定されることが多いです。キャッシュの問題をデバッグする際は、保存されている有効期限タイムスタンプを人が読める日付に変換することが頻繁に必要になります。
ログ分析: サーバー ログには通常 Unix タイムスタンプが含まれます。これらを読める日付に変換することが、ログエントリを実際のイベントと結びつける第一歩です。
データベース保存: タイムスタンプを文字列形式ではなく整数として保存することで、タイムゾーン変換バグを回避でき、ソート、範囲クエリ、計算が簡単になります。「過去 7 日間のすべてのレコード」を取得するクエリは WHERE created_at > (NOW_UNIX - 604800) のようになります。
