Unix タイムスタンプ変換ツール
Unix タイムスタンプと日付を相互に変換します。
このツールについて
秒・ミリ秒・マイクロ秒の Unix タイムスタンプを ISO 8601、ローカル時刻、相対時間に変換したり、任意の日付文字列をタイムスタンプに戻したりできます。
使い方
- 秒・ミリ秒・マイクロ秒の Unix タイムスタンプ、または任意の日付文字列を貼り付けます。
- 単位は桁数から判別されます。
- ISO 8601、ローカル時刻、RFC 2822、相対表記で日付を確認し、必要なものをコピーします。
よくある質問
- Unix タイムスタンプとは何ですか?
- 1970 年 1 月 1 日 00:00:00 UTC からの秒数で、Unix エポックと呼ばれます。世界中どこでも同じ値になるため、時点を保存するのに最適です。
- 秒とミリ秒、どちらですか?
- 現在のタイムスタンプは秒単位なら 10 桁、ミリ秒単位なら 13 桁です。Unix ツールや多くの API は秒を使い、JavaScript の Date.now() はミリ秒を返します。
- 2038 年問題とは何ですか?
- タイムスタンプを符号付き 32 ビット整数で保存しているシステムは、2038 年 1 月 19 日にオーバーフローします。最近のシステムは 64 ビットの値を使っているため影響を受けません。
- 1970 年より前の日付は Unix タイムスタンプでどう表しますか?
- 負の数で表します。-86400 はエポックの 1 日前、1969 年 12 月 31 日 00:00 UTC で、この変換ツールはマイナス記号を受け付けます。古いシステムやライブラリには負のタイムスタンプを拒否するものがあるため、生年月日のような過去の日付をこの方法で保存する前に確認してください。
- Unix タイムスタンプにうるう秒は含まれますか?
- いいえ。Unix 時間はすべての日をちょうど 86,400 秒として扱い、うるう秒を無視します。うるう秒が発生すると、システムクロックは 1 秒を繰り返すか、Google や AWS のように数時間かけて分散させます。後者はスミアリング(smearing)と呼ばれます。ほとんどすべてのアプリケーションでは、これを気にする必要はありません。
- Excel や Google スプレッドシートで Unix タイムスタンプを変換するには?
- =A1/86400 + DATE(1970,1,1) を使い、セルを日付と時刻の形式に設定します。結果は UTC なので、現地時刻にするにはオフセットを 24 で割った値を足します。ミリ秒のタイムスタンプなら、86400 ではなく 86400000 で割ってください。
各言語で現在の Unix タイムスタンプを取得する方法
ほとんどの言語では、現在のエポック時間を 1 回の呼び出しで取得できます。JavaScript の Date.now() はミリ秒を返すため、秒が必要なら Math.floor(Date.now() / 1000) を使います。Python の time.time() は秒を浮動小数点数で返し、シェルでは date +%s が秒を出力します。Go には time.Now().Unix()、Java には Instant.now().getEpochSecond()、PostgreSQL には extract(epoch from now()) があります。このページの上部には、現在の値が秒とミリ秒でリアルタイムに表示されます。
逆方向の変換も同じくらい簡単です。JavaScript では new Date(ts * 1000).toISOString()、Python では datetime.fromtimestamp(ts, tz=timezone.utc)、Linux では date -d @1762540800、macOS では date -r 1762540800 を使います。最もよくあるバグは単位の混同です。ミリ秒を想定する関数に秒を渡すと 1970 年 1 月になり、秒を想定する場所にミリ秒を渡すと数万年先の日付になります。
ISO 8601 と Unix 時間: 保存するならどちらの形式?
Unix 時間は単一の数値なので、比較、並べ替え、計算が簡単で、タイムゾーンの混乱もありません。2026-11-07T20:00:00Z のような ISO 8601 の文字列は人が読みやすく、2026-11-07T21:00:00+01:00 のように必要に応じてオフセットを含められます。どちらも正確な瞬間を表します。RFC 3339 は ISO 8601 をより厳密にしたインターネット向けのプロファイルで、ほとんどの API が実際に従っているのはこちらです。
よい目安は、瞬間をネイティブのタイムスタンプ型か Unix 時間で保存し、API やログでは Z かオフセット付きの ISO 8601 で送ることです。2026-11-07 20:00 のようにタイムゾーンがまったくない文字列は避けてください。読む側がそれぞれ異なるタイムゾーンを想定するかもしれません。このエポック変換ツールはそうした文字列を UTC として読み込み、その旨を注記で示します。06/Nov/2026:09:15:02 +0000 のようなログの形式も解釈できます。
変換したタイムスタンプが数時間ずれるのはなぜですか?
Unix タイムスタンプにはタイムゾーンがなく、UTC のエポックからの秒数を数えたものです。変換した日付が数時間ずれて見える場合、たいていタイムスタンプは正しく、問題は表示のほうです。ここで「ISO 8601 (UTC)」の行と「ローカル」の行を比べてください。同じ瞬間を、UTC とブラウザーのタイムゾーンでそれぞれ表示しています。タイムゾーンを指定せずに日付をフォーマットするコードは、マシンのローカルタイムゾーンを使います。
もう 1 つのよくある原因は、現地の時計の時刻から作られたタイムスタンプです。Python の datetime.utcnow().timestamp() が典型例で、タイムゾーン情報のない UTC の値が現地時刻として扱われるため、結果が UTC オフセットの分だけずれます。代わりに datetime.now(timezone.utc) を使ってください。ちょうど 3600 秒や 7200 秒の差がある場合は、この種のバグが疑われます。タイムゾーン変換ツールでは、各タイムゾーンで時計が何時を指していたかを確認できます。
主な Unix タイムスタンプ
Unix 時間の節目となる値です(1970 年 1 月 1 日 UTC からの秒数)。
| タイムスタンプ | 日時(UTC) | なぜ重要か |
|---|---|---|
0 | 1970-01-01T00:00:00Z | Unix エポック: カウントの起点 |
1000000000 | 2001-09-09T01:46:40Z | 10 億秒 |
1234567890 | 2009-02-13T23:31:30Z | 1 から 0 までの数字が順に並ぶ、プログラマーが祝った瞬間 |
2000000000 | 2033-05-18T03:33:20Z | 20 億秒 |
2147483647 | 2038-01-19T03:14:07Z | 符号付き 32 ビット整数の最大値: 2038 年問題 |
4294967295 | 2106-02-07T06:28:15Z | 符号なし 32 ビット整数の最大値 |
うまく動かない、または結果がおかしいですか? このツールの問題を報告