コンテンツにスキップ
DevLab

タイムスタンプ変換ツール

Unix タイムスタンプ（秒・ミリ秒）と ISO 8601 / 日本時間 / UTC を相互変換。ログの解析・API のデバッグ・データ移行時の日時確認に。

完全無料 登録不要 ブラウザ完結 5 言語対応 ダークモード
現在のタイムスタンプ
秒:
ミリ秒:
うまく動かない・表示がおかしい場合は お問い合わせフォーム からご報告ください。

📖 つまずきやすいポイント

Unix タイムスタンプ (秒 / ミリ秒) と ISO 8601 / JST / UTC を相互に変換します。秒かミリ秒かは桁数から推測しています — 13 桁以上ならミリ秒、10 桁なら秒として扱います。これは実務上ほぼ当たる経験則であって、仕様ではありません。タイムスタンプという値そのものには単位もタイムゾーンも書かれていないので、最終的な判断は「その値を出したシステムの仕様」でしか付きません。

ケース 何が起きるか どうする
1970 年や 5 万年後になる 秒とミリ秒を取り違えた典型的な症状です。ミリ秒の値を秒として読むと西暦 55000 年前後に、秒の値をミリ秒として読むと 1970 年 1 月 20 日前後になります。言語ごとに既定の単位が違うのが原因で、JavaScript の Date.now() と Java の System.currentTimeMillis() はミリ秒、PHP の time()・Python の time.time()・シェルの date +%s は秒です。JSON を介して別の言語に渡す境目で必ず起きます。 桁数を数えるのがいちばん速い判別法です。2001 年 9 月 9 日以降、秒は 10 桁 (2286 年まで)、ミリ秒は 13 桁 (2286 年まで) なので、当面はこの 2 つを見分けるだけで足ります。設計側では、API のフィールド名に単位を入れてしまうのが最も事故が少ないです — expires_at ではなく expires_at_ms と書けば、受け取る側が誤解しようがありません。そもそも ISO 8601 文字列で渡せるなら、そのほうが安全です (人間が目で読めるので、この種の間違いがコードレビューで止まります)。
同じ日時文字列が環境によって違う時刻になる タイムゾーンを書かない文字列は解釈が実装依存です。JavaScript では 2024-01-01 (日付のみ) は UTC、2024-01-01T00:00:00 (時刻付き) はローカル時刻と解釈されます — 1 文字違うだけで 9 時間ずれます。さらに 2024-01-01 09:00:00 のようなスペース区切りは ISO 8601 でも ECMAScript でも規定外で、ブラウザごとの独自解釈になります。サーバーが UTC、開発機が JST という構成では、ローカルでは正しく動くのに本番だけ 9 時間ずれるという形で表面化します。 タイムゾーンを省略した文字列を書かないでください。必ず Z か +09:00 を付けます — 2024-01-01T00:00:00Z なら、どの実装でも同じ 1 つの瞬間を指します。運用の原則は「保存は UTC、表示のときだけローカルに変換」です。データベースの列型にも同じ罠があります — MySQL の TIMESTAMP はセッションのタイムゾーンで変換されて出てきますが、DATETIME は書いた文字列がそのまま返ります。サーバー移設で time_zone が変わると、TIMESTAMP 列だけが過去のデータごとズレて見えます。
固定オフセットで保存して夏時間や法改正でずれる +09:00 のようなオフセットは「その瞬間のズレ」であって「地域」ではありません。JST は夏時間が無いので日本国内だけなら問題は起きにくいのですが、米国や欧州のユーザーを扱った瞬間に破綻します — ニューヨークは -05:00 と -04:00 を年 2 回行き来するので、3 月に -05:00 で保存した「毎週月曜 9 時の会議」は、4 月には 8 時に鳴ります。オフセットは法律で変わります — 実際にサモアは 2011 年に日付変更線をまたぎ、12 月 30 日という日が存在しない年がありました。 過去の記録はオフセット付きの瞬間 (UTC) で、未来の予定は IANA タイムゾーン名 + ローカル時刻で保存してください。この 2 つは目的が違います — ログは「いつ起きたか」なので瞬間で十分ですが、予定は「現地の 9 時」という約束なので Asia/Tokyo や America/New_York という地域名で持たないと、法改正のたびに予定が動いてしまいます。タイムゾーンのデータベース (tzdata) は年に数回更新されます — コンテナイメージを固定していると古い規則のまま動き続けるので、ベースイメージの更新は「セキュリティ以外の理由でも必要」と覚えておいてください。

Unix タイムスタンプは「1970-01-01T00:00:00Z からの経過秒数」ではありません — 正確にはうるう秒を無かったことにした通算秒です。実際の経過秒数とは 2026 年時点で 27 秒ずれています。日常のアプリケーションでは無視して構いませんが、金融取引の順序や分散システムの因果関係を扱うなら、この 1 秒が問題になります — うるう秒の挿入時、システムによっては同じタイムスタンプが 2 回出るか、時計が 1 秒巻き戻ります。Google や AWS は 1 日かけて少しずつ時計を遅らせる smear 方式を採っており、その日は他社の時計と最大 0.5 秒ずれます。時刻の一意性が要る場面では、タイムスタンプを主キーにせず単調増加の ID を併用してください。

📖 使い方

  1. 1
    タイムスタンプまたは日時文字列を入力
    入力欄に Unix タイムスタンプ（秒 or ミリ秒）または ISO 8601 / RFC 2822 形式の日時文字列を入力します。秒とミリ秒は桁数で自動判定されます。
  2. 2
    変換結果を確認
    Unix 秒・ミリ秒・ISO 8601 (UTC / JST)・RFC 2822・曜日・相対時間がまとめて表示されます。各行をクリックするとその値をコピーできます。
  3. 3
    +1日・-1時間などのボタンで調整
    -1日・-1時間・+1時間・+1日のボタンで入力値をオフセットして変換結果を確認できます。境界値テストやログ解析の前後時刻確認に便利です。

❓ よくある質問

秒とミリ秒はどう区別していますか?
桁数で自動判定しています。13 桁以上の数値はミリ秒として処理し、10 桁の数値は秒として処理します。
JST (日本標準時) とは何ですか?
JST は Japan Standard Time (日本標準時) で、UTC+9 です。UTC に 9 時間を加算した時刻になります。
Unix タイムスタンプとは何ですか?
1970 年 1 月 1 日 00:00:00 UTC (Unix エポック) からの経過秒数です。プログラミングやデータベースで日時を数値で扱う際の標準形式です。
🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。

※ 不具合再現のため、ブラウザ情報 (UA / 画面サイズ / 言語 / URL) を自動で送信します