タイムスタンプ変換ツール
Unixタイムスタンプと日時フォーマットの相互変換
タイムスタンプ → 日付
日付 → タイムスタンプ
グローバルタイムゾーン比較
よく使うフォーマット例
タイムスタンプとは？
タイムスタンプ（Timestamp）は特定時刻を表す数値です。Unixタイムスタンプは1970年1月1日00:00:00 UTC（Unixエポック）から指定時刻までの秒数であり、コンピュータシステムで時刻を表現する標準方式で、クロスプラットフォーム・クロスタイムゾーンで一意な特徴があります。タイムスタンプは秒単位（10桁）とミリ秒単位（13桁）があり、秒単位はUnix/Linuxシステムで、ミリ秒単位はJavaScriptなどのプログラミング言語でよく使用されます。
使い方
タイムスタンプから日付へ
- 左側のカードにUnixタイムスタンプを入力してください
- 変換先のタイムゾーンを選択してください（例：北京時間 UTC+8）
- 変換ボタンをクリックして変換された日時を確認してください
- 結果には、標準形式、ISO 8601、中国形式などが含まれます
日付からタイムスタンプへ
- 右側のカードで日付と時刻を選択してください
- その日付と時刻が使用する元のタイムゾーンを選択してください
- 変換ボタンをクリックしてUnixタイムスタンプを取得してください
- 結果には、秒とミリ秒のタイムスタンプが含まれます
タイムゾーンのヒント
- ソース値が秒単位かミリ秒単位かを確認してください。10桁と13桁のタイムスタンプを混同すると、日付が誤る一般的な原因となります。
- 人が読める形式の日付を変換する際は、必ず意図したタイムゾーンを確認してください。特にログ、スケジュールジョブ、リージョンをまたぐシステムでは重要です。
利用シーン
仕組み
UnixタイムスタンプはUnixエポック（1970-01-01T00:00:00Z）からの経過時間を数えます。これはPOSIX時刻がすべての時刻をラベル付けするための原点です。POSIX時刻はうるう秒を意図的に無視します。各暦日は厳密に86,400秒として扱われるため、うるう秒の挿入をまたぐ2つのタイムスタンプは厳密な原子時計のカウントと1秒ずれますが、その代わりにエポック秒とUTC暦日フィールドの間の変換が86,400による単純なdivmodで済みます。 日常的に登場する2つのフォーマットは秒（現在10桁、例：1717000000）とミリ秒（13桁、例：1717000000000）です。JavaScriptのDate.now()はエポックからのミリ秒を返し、`new Date(ms)`はミリ秒を受け付けます。一方、Unixの`date +%s`、Goのtime.Unix、ほとんどのデータベースのTIMESTAMPカラムは秒を使用します。桁数による判別が一般的な方法です。10桁の値を秒として読めば2001〜2286年の範囲に入り、同じ値をミリ秒として読めば1970年内になります。 タイムスタンプの表示にはタイムゾーンが必要です。UTCは接尾辞`Z`で表記し、他のオフセットは`±HH:MM`を使用します（例：中国標準時`+08:00`、米国東部標準時`-05:00`）。ISO 8601は複数の任意セパレータを許容しますが、RFC 3339はより厳格なプロファイルでセパレータを固定しているため、API仕様では明示的なオフセット付きのRFC 3339が通常要求されます。エポック秒を32ビット符号付き整数で保存するレガシーシステムは、最大正値2147483647でオーバーフローし、これは2038-01-19T03:14:07Zに相当します（Y2038問題）。64ビットストレージではこの境界は人間にとって意味のある範囲をはるかに超えます。
- Unixエポックは1970-01-01T00:00:00Zに固定されており、POSIX時刻はうるう秒を無視するため、すべての日は厳密に86,400秒として扱われる。
- JavaScript Date.now()はミリ秒を返す。`Math.floor(Date.now() / 1000)`で秒単位のタイムスタンプに変換。
- Y2038の境界：符号付き32ビットタイムスタンプは2147483647 = 2038-01-19T03:14:07Zでオーバーフロー。64ビットストレージではこの問題を回避。
- ISO 8601とRFC 3339：RFC 3339はより厳格なISO 8601プロファイルで、明示的なオフセット（`Z`または`±HH:MM`）を要求。APIやログではRFC 3339が推奨。
- ECMAScript Dateはエポックから±100,000,000日（≈ ±273,785年）に制限。`new Date(8.64e15)`と`new Date(-8.64e15)`が絶対的な境界。
- JWTの`exp`、`iat`、`nbf`クレーム、`Cache-Control: max-age`、Cookieの`Expires`はすべてUnix秒を使用（RFC 7519、RFC 7234）。`Math.floor(Date.now()/1000)`に対して直接加算・減算可能。
- タイムゾーンは表示される日時に影響するが、タイムスタンプ値自体には影響しない。同じエポック秒がUTC+8とUTC-5で異なる壁時計時刻として表示される。
使用例
10桁 Unix タイムスタンプを可読な日付に変換
入力: 1781526600
UTC: 2026-06-15 12:30:00
北京 (UTC+8): 2026-06-15 20:30:00
ISO 8601: 2026-06-15T12:30:00Z
POSIX: IEEE 1003.1 では Unix 時刻を 1970-01-01 00:00:00 UTC（Epoch）からの経過秒として定義
ISO: ISO 8601 は曖昧さのない日時表現として YYYY-MM-DDThh:mm:ssZ 形式を定義日付からタイムスタンプへの逆変換
入力: 2026-01-01 00:00:00 (UTC)
秒（10桁）: 1767225600
ミリ秒（13桁）: 1767225600000
Unix コマンド: date -d @1767225600
注意: JavaScript の Date.getTime() はミリ秒を返し、Python の time.time() は秒（float）を返す
POSIX: time_t 型は伝統的に 32 ビットまたは 64 ビット符号付き整数秒とミリ秒の見分け方
1781526600 -> 10桁、秒 -> 2026-06-15 12:30:00 UTC
1781526600000 -> 13桁、ミリ秒 -> 2026-06-15 12:30:00.000 UTC
よくある不具合: 13桁の値を秒として読むと約 74,000 年になる
見分け方: 10〜11桁 = 秒（1970〜2286）、13桁 = ミリ秒（JavaScript の既定）JWT の exp クレームをデコード
JWT ペイロード: { "exp": 1798617600 }
デコード結果: 2027-01-01 00:00:00 UTC
現在時刻: 1781526600
有効期間: 17,091,000 秒（残り約198日）
RFC: RFC 7519 セクション 2 では NumericDate を Epoch からの秒数として定義2038年問題の境界チェック
符号付き32ビットの最大タイムスタンプ: 2147483647
デコード結果: 2038-01-19 03:14:07 UTC
1秒後: 2147483648 -> レガシー32ビットシステムでオーバーフロー
対処: 64ビット time_t を使用（最近の Linux/macOS の既定）または ISO 8601 文字列で保存
POSIX: 32ビット time_t システムは 2038-01-19 以降にラップアラウンドするよくある質問
Unixタイムスタンプとは何ですか？
1970-01-01 00:00:00 UTC（「Unixエポック」）から経過した秒数です。JavaScriptや多くのAPIは、同じエポックからのミリ秒数（Unixタイムスタンプ × 1000）を使用します。本ページは両方を受け付け、対応する日時をローカル時刻とUTCで表示します。
秒、ミリ秒、マイクロ秒、ナノ秒の違いは？
システムによって精度が異なります。Unixの`time()`は秒、JavaScriptのDate.now()はミリ秒、JavaのInstantはナノ秒に対応しています。本ページは桁数で自動判別します。10桁＝秒（2001〜2286年範囲）、13桁＝ミリ秒、16桁＝マイクロ秒、19桁＝ナノ秒です。
なぜ2038年1月19日が重要なのですか？
「2038年問題」のためです。32ビット符号付きUnixタイムスタンプは2038-01-19の03:14:07 UTCにオーバーフローします。32ビットtime_tを使用しているシステムは1901年に巻き戻ります。最新の64ビットシステムは数十億年は問題ありませんが、レガシーな組み込みシステムは対応が必要です。
タイムゾーンはどう扱われますか？
Unixタイムスタンプは本質的にUTCです。本ページではローカル時刻、UTCを表示し、追加表示用に任意のIANAタイムゾーン（Asia/Shanghai、America/New_York、Europe/London）を選択できます。サマータイムはゾーンごとに自動適用されます。
なぜ「YYYY-MM-DD」を解析するとUTCとみなされる場合があるのですか？
タイムゾーンのないISO 8601日付は曖昧です。JavaScriptのDateコンストラクタは、日付のみの文字列をUTC、日時文字列をローカルとして扱います。これは1日ずれるバグの有名な原因です。本ページではどのタイムゾーンが適用されるかを明示します。
変換はローカルで行われますか？
はい。計算はJavaScriptのDateとIntl.DateTimeFormatで行われます。タイムスタンプはアップロードされません。
未来のタイムスタンプを生成できますか？
はい。未来の日時を選択すると、対応するタイムスタンプが返されます。JWTのexpクレーム設定、cronジョブのテスト日時、コード内のキャッシュ有効期限などに便利です。