コンテンツへスキップ

Unixタイム変換

ブラウザ内処理ファイルはアップロードされませんこの処理はブラウザ内で完結します。ファイルはどこにも送信されません。

エポック秒・ミリ秒と日時を相互に変換します。端末の時刻とUTCを並べて表示し、ISO 8601 形式も時差つき・UTCの両方を出します。いまのUnixタイムも常に表示しています。

入力

いまのUnixタイム
ミリ秒
この端末の時間帯

自動では、桁を見て秒かミリ秒かを判定します(1000億以上ならミリ秒)。判定が意図と違うときは、単位を明示してください。

変換結果

まだ何もありません
エポック秒1788566400日時2026-09-05 09:00 (JST)2026-09-05 00:00 (UTC)ISO 2026-09-05T09:00+09:00ミリ秒(13桁)で貼っても、桁数から自動で見分けます。
エポック秒は「1970年1月1日 00:00:00 UTC からの秒数」で、時差を持たない。端末の時刻とUTCを並べているのは、どちらの時刻を見ているかを取り違えないため。
ツール一覧

特長

秒とミリ秒を取り違えない
同じ時刻でも、ログは秒、JavaScript のAPIはミリ秒で持っていることが多く、取り違えると1970年や遠い未来に飛びます。桁から単位を判定し、どちらとして読んだかを画面に出します。明示的な指定もできます。判定が黙って行われると、結果が正しいのかどうかを確かめる手がかりがなくなるため、必ず「どちらとして読んだか」を書いています。
ローカルとUTCを並べて出す
時刻のずれの原因は、ほとんどが「片方がUTCで片方が現地時刻」です。端末の時刻とUTCを同時に、時差の値つきで表示するので、どちらの表記を見ているのかが一目で分かります。ページ上部にはこの端末の時間帯の名前も出しているため、設定そのものが想定と違っていた場合も、その場で気づけます。
ISO 8601 を時差つきでも出す
ブラウザ標準の toISOString は必ずUTC(末尾がZ)になります。現地時刻を +09:00 のような時差つきで書きたい場合はそのままでは足りないため、両方の形式を出しています。現地時刻の末尾に Z を付けてしまう取り違えは、9時間ずれた記録が残る典型的な原因です。

使い方

  1. 変換の向きを選ぶ

    「エポック → 日時」か「日時 → エポック」を選びます。ページの一番上には、いまのUnixタイムが秒とミリ秒の両方で出ているので、そのままコピーすることもできます。

  2. 値を入れる

    数値または日時を入力欄に入れます。「現在時刻を入れる」を押すと、選んでいる向きに合わせて現在の値が入ります。エポック側では単位(自動・秒・ミリ秒)を、日時側では入力の時間帯(この端末・UTC)を選べます。

  3. 結果を読む

    端末の時刻、UTC、ISO 8601 の2形式、エポック秒とミリ秒、現在との差が一覧で出ます。それぞれの値の右にあるボタンで、その1行だけをコピーできます。

Unixタイムの基礎

Unixタイムとは何か
1970年1月1日 00:00:00 UTC からの経過秒数です。時差も夏時間も含まない1つの数値なので、世界のどこで生成しても同じ瞬間を指します。「どの地域の時刻か」を持たないことが利点であり、同時に、そのまま人に見せると読めないという欠点でもあります。ログやデータベースに時刻をこの形で保存しておくと、後から任意の時間帯に直して表示できます。逆に、現地時刻の文字列だけを保存してしまうと、時差の情報が失われて元の瞬間を復元できなくなります。
なぜミリ秒の値が出回っているのか
JavaScript の Date.now() や Java の System.currentTimeMillis() がミリ秒を返すためです。値は秒の1000倍なので、桁数が3つ増えます。1970年より後の現実的な日付なら、秒は10桁、ミリ秒は13桁になります。ここでの自動判定はこの桁数の差を見ています。ミリ秒の値を秒として読むと5万年以上先の日付になり、逆に秒の値をミリ秒として読むと1970年の直後になります。結果があきらかにおかしいときは、まず単位を疑ってください。
2038年問題
経過秒数を符号付き32ビット整数で保持している古いシステムは、2038年1月19日 03:14:07 UTC を超えると値があふれ、1901年に戻ってしまいます。64ビットで保持していれば問題は起きません。このページの計算は倍精度浮動小数点で行うため、この上限はありません。似た問題として、有効期限や満期日のように未来の日付を扱う処理では、2038年より手前で先に不具合が現れることがあります。
うるう秒は含まれない
Unixタイムは「1日はちょうど86400秒」として数えるため、実際に挿入されたうるう秒は含まれていません。そのため2つのUnixタイムの差は、厳密な経過秒数とは最大で数十秒ずれます。日常の用途では問題になりませんが、天文や測位のように厳密な経過時間が必要な場面では別の尺度が使われます。うるう秒が挿入される瞬間、多くのシステムは同じUnixタイムを2回繰り返すか、時計をわずかに遅らせて吸収します。どちらの方式かによって、その1秒間に記録された時刻の意味が変わります。

よくある質問

「この端末の時刻」は何を基準にしていますか?
ブラウザが持っているタイムゾーン設定です。パソコンやスマートフォンの時刻設定を変えると、この表示も変わります。時間帯の名前(Asia/Tokyo など)と時差を上部に出しているので、意図した設定かどうかを確認できます。サーバーの時刻と見比べたい場合は、UTC の行を基準にしてください。UTC は端末の設定に左右されません。
夏時間(サマータイム)のある地域でも正しく出ますか?
出ます。時差はその日時の時点のものを使って計算しているため、夏時間の期間中と期間外で自動的に切り替わります。ただし夏時間の切り替わりの瞬間には、存在しない時刻(飛ばされる1時間)と、2回ある時刻が生じます。前者を入力した場合は、ブラウザの規則に従って近い時刻に寄せて解釈されます。後者、つまり同じ時刻が2回ある場合は、どちらか一方として解釈されます。曖昧さを避けたい場合は、入力に +09:00 のような時差を直接書くか、UTC で入力してください。
負の値やミリ秒未満は扱えますか?
負の値は1970年より前を表し、そのまま扱えます。小数点付きの秒(1786500000.5 など)も受け付け、ミリ秒に換算します。ただし表示上の秒は整数までで、それより細かい値は結果のミリ秒欄で確認してください。極端に大きな値を入れると扱える範囲を超え、その旨が表示されます。範囲はおよそ1970年を中心に前後27万年です。
日時の入力はどの書き方に対応していますか?
「2026-08-15」「2026-08-15 12:34:56」「2026/8/15 12:34」「2026-08-15T12:34:56Z」「2026-08-15T12:34:56+09:00」に対応しています。末尾に Z や時差が付いている場合は、時間帯の切り替えより入力の指定を優先します。時刻を省いた場合は、その日の0時0分0秒として扱います。存在しない日付(2月30日など)は、近い日付に寄せずにエラーとして返します。黙って3月2日に直すより、入力が間違っていると伝えたほうが安全だからです。
入力した値は送信されますか?
送信されません。計算はすべてブラウザ内で行われます。ログに含まれる時刻のような、そのままでは外に出せない値でも扱えます。画面上部の現在時刻も、外部の時刻サーバーではなく端末の時計から読んでいます。
スポンサーリンク