Unix タイムスタンプ変換 — エポック秒から日時、日時からエポック秒

エポックの秒、ミリ秒、マイクロ秒、ナノ秒を任意のタイムゾーンの日時に変換、その逆も。現在時刻の表示、一括変換、コードスニペット付き。

現在の Unix 時刻
秒
—
ミリ秒
—

タイムスタンプ → 日付

秒、ミリ秒、マイクロ秒、ナノ秒のいずれか。負の値は 1970 年より前を表します。
解釈
秒
UTC
Thu 2025-10-16 00:00:00.000 (UTC+00:00)
現地時刻
UTC
ISO 8601 (UTC)
2025-10-16T00:00:00.000Z
ISO 8601 (UTC)
RFC 2822
相対時間
秒
1760572800
ミリ秒
1760572800000
マイクロ秒
1760572800000000
ナノ秒
1760572800000000000

日付 → タイムスタンプ

YYYY-MM-DD HH:mm:ss は右で選んだタイムゾーンで解釈されます。Z やオフセット付きの ISO 8601、および RFC 2822 は、それ自体のタイムゾーンを持ちます。
Unix 秒
1767225600
ミリ秒
1767225600000
ISO 8601 (UTC)
2026-01-01T00:00:00.000Z
UTC

日・週・月・年の開始と終了

UTC 基準。週は月曜日始まり(ISO 8601)

一括変換

タイムスタンプは UTC の ISO 8601 に、日付は Unix 秒に変換されます。最大 5,000 行まで。
1700000000s
1760572800000ms
-1s
2038-01-19 03:14:07日付
0s

コードで現在のタイムスタンプを取得

Math.floor(Date.now() / 1000)   // seconds
Date.now()                      // milliseconds

すべてブラウザ内で動作します。入力内容が送信・保存されることはありません。 すべての無料ツールを見る.

不具合や改善できそうな点を見つけましたか?いただいたメッセージはすべて読み、すぐに対応します。

この Unix タイムスタンプ変換ツールは、エポック値を読める日時に、日時をエポック値に変換します。UTC、あなたのタイムゾーン、ブラウザが知っている約 400 の IANA タイムゾーンのどれでも使えます。1760572800、1760572800000、ログ行にある 19 桁のナノ秒の値などを貼り付けると、桁数から単位を判定します。値が曖昧な場合は単位を手動で指定することもできます。

大きな値や特殊な値も正確に扱います。数字は BigInt として解析するので、ナノ秒のタイムスタンプも丸められずに最後の桁まで保たれます。1970 年より前の負のタイムスタンプは正しいミリ秒に切り捨てられ、JavaScript の日付の範囲(およそ紀元前 271,821 年〜西暦 275,760 年)を超える値は「Invalid Date」と表示するのではなく範囲外と報告します。夏時間の切り替えを含むタイムゾーンのオフセットは、ブラウザ自身のタイムゾーンデータを使います。入力した内容がページの外に出ることはありません。

使い方

  1. 最初の欄にタイムスタンプを貼り付けます。表に、UTC、あなたのタイムゾーン、選択したタイムゾーン、ISO 8601、RFC 2822、相対時間で表示されます。
  2. 単位が違う場合(12 桁の値は西暦 5138 年以降の秒にも 1973 年のミリ秒にもなりえます)は、「単位」メニューで選びます。
  3. 逆に変換するには、日時を YYYY-MM-DD HH:mm:ss の形式で入力し、その日時のタイムゾーンを選びます。Z やオフセット付きの ISO 文字列はそのまま読み取ります。
  4. 「今月のすべて」のような範囲指定のクエリには開始・終了の表を、CSV やログの値の列には一括変換のボックスを使います。
  5. 各値はボタンでコピーできます。コードで現在のタイムスタンプを取得するには、お使いの言語のスニペットをコピーしてください。

よくある質問

Unix タイムスタンプとは何ですか?

Unix タイムスタンプ(エポックタイム)は、1970 年 1 月 1 日 00:00:00 UTC からの経過秒数で、うるう秒は数えません。タイムゾーンを持たないので、同じ瞬間はどこでも同じタイムスタンプになり、だからこそデータベースや API で使われます。多くのシステムは代わりにミリ秒で保存し(JavaScript の Date.now()、Java の currentTimeMillis)、マイクロ秒やナノ秒で保存するシステムもあります。

タイムスタンプが秒かミリ秒かを見分けるには?

桁数を数えてください。現在のタイムスタンプは、秒なら 10 桁、ミリ秒なら 13 桁、マイクロ秒なら 16 桁、ナノ秒なら 19 桁です。このツールはこの境界を自動で使います。唯一曖昧なのは 11〜12 桁の範囲で、遠い未来の秒か 1970 年代初めのミリ秒のどちらかです。その場合は手動で単位を選んでください。

2038 年問題とは何ですか?

Unix 時間を符号付き 32 ビット整数で保存するシステムは、2,147,483,647 までしか数えられず、これは 2038 年 1 月 19 日 03:14:07 UTC にあたります。その 1 秒後には値が負の数に折り返し、1901 年 12 月として読まれてしまいます。現代の OS、プログラミング言語、データベースは 64 ビットの時刻を使っていますが、古い組み込み機器、ファイル形式、32 ビットの INT として宣言されたデータベースの列には今もこの問題があります。

Unix タイムスタンプにはうるう秒が含まれますか?

いいえ。Unix 時間は 1 日を常にちょうど 86,400 秒として扱うので、うるう秒は数えられず、うるう秒が入るとタイムスタンプは 1 秒間繰り返されるか止まります。そのおかげで日付の計算は単純になりますが、その代わり原子時(TAI)とは累積したうるう秒の分(現在 37 秒)ずれています。ほとんどのアプリケーションの作業では問題になりません。

Unix タイムスタンプは負の値になりますか?

はい。負の値は 1970 年からさかのぼって数えます。-1 は 1969 年 12 月 31 日 23:59:59 UTC、-86400 はその日の始まりです。ほとんどの言語は負のタイムスタンプを正しく扱いますが、古い API や表計算の関数の中には受け付けないものもあるので、生年月日や歴史上の日付をエポック値で保存する前に確認してください。

変換した時刻が数時間ずれて見えるのはなぜですか?

ほぼ必ずタイムゾーンの取り違えです。タイムスタンプは正しいのに、ローカル時刻を期待していたところで UTC で表示された、またはローカルの日時文字列が UTC として解析された、というケースです。タイムスタンプ自体がタイムゾーンを持つことはありません。ここではタイムゾーンの選択を確認し、コードではオフセットのない日時文字列が意図したタイムゾーンで解釈されるようにしてください。

秒、ミリ秒、マイクロ秒、ナノ秒:どこで何が使われるか

• 秒(10 桁):Unix と POSIX の time()、PHP の time()、Python の int(time.time())、PostgreSQL の EXTRACT(EPOCH)、JWT の exp/iat/nbf クレーム、ほとんどの HTTP API。

• ミリ秒(13 桁):JavaScript の Date.now()、Java の System.currentTimeMillis()、Elasticsearch や多くの JSON API、Kafka のレコードのタイムスタンプ。

• マイクロ秒(16 桁):PostgreSQL の内部のタイムスタンプ保存、Python の datetime の精度、Google BigQuery の TIMESTAMP_MICROS。

• ナノ秒(19 桁):Go の time.UnixNano()、Python の time.time_ns()、InfluxDB と Prometheus の remote-write、Linux の clock_gettime。JavaScript の数値ではこれを正確に保持できないため、このツールは BigInt として解析します。

2 つのシステムの値が 1,000 倍ずれているなら、一方は秒で、もう一方はミリ秒です。「日付が 1970 年になる」「日付が 50,000 年になる」というバグのほとんどは、このたった 1 つの間違いが原因です。

タイムゾーンと夏時間:起こりうる問題

タイムスタンプをローカル時刻に変換するのは常に一意です。1 つの瞬間は、各タイムゾーンで 1 つの時計の表示に対応します。逆方向はそうではありません。時計を進めるときには、切り替え日の 02:30 のようなローカル時刻は存在せず、時計を戻すときには 01:30 が 2 回あります。

この変換ツールは、JavaScript の Temporal API の初期設定と同じルールに従います。飛ばされた時刻は切り替え前のオフセットで読み(つまり 02:30 は夏時間の 03:30 になります)、繰り返される時刻は最初の方として解決します。コードが別のルールを使っている場合、毎年この 2 つの日付の前後で結果が 1 時間ずれることがあります。

最も安全なのは、瞬間を UTC のタイムスタンプか明示的なオフセット付きの ISO 8601 文字列で保存・送信し、表示のときだけローカル時刻に変換することです。その際は、1 年の半分は誤りになる -05:00 のような固定オフセットではなく、America/Toronto のような IANA のタイムゾーン名を使ってください。

ISO 8601、RFC 2822、Unix 時間の比較

ISO 8601(2026-10-16T08:00:00Z や 2026-10-16T04:00:00-04:00)はテキストとして正しく並べ替えられ、曖昧さがなく、JSON API、HTML の datetime 属性、ほとんどのデータベースが期待する形式です。人が値を読む可能性があるなら、常にこれを使ってください。

RFC 2822(Fri, 16 Oct 2026 08:00:00 +0000)はメールと HTTP ヘッダーの形式です。読みやすいもののテキストとしては並べ替えられず、1900 年以降の年しか定義されていません。

Unix タイムスタンプは最もコンパクトで比較も最速ですが、変換ツールなしでは読めず、単位の手がかりもありません。妥当なルールは、システムの内部では Unix 時間、システムの境界では ISO 8601 です。

関連する無料ツール

  • cron 式ジェネレーター — ドロップダウンから cron スケジュールを作成するか貼り付けると、わかりやすい日本語で読み、次の 10 回の実行時刻をローカル時刻と UTC で確認できます。無料、ブラウザで動作。
  • JWT デコーダー — JWT のヘッダーとペイロードをデコードし、有効期限をわかりやすく表示し、HS・RS・PS・ES の署名を検証したり、新しいトークンに署名したりできます。何もブラウザの外に出ません。
  • UUID 生成 — UUID v4 や時系列順の v7、ULID、NanoID を一括生成。ID を貼り付ければ、バージョンと埋め込まれたタイムスタンプも確認できます。
  • 進数変換 — 任意の大きさの整数を、2 進数、8 進数、10 進数、16 進数、32 進数、36 進数、そして 2〜36 の任意の進数の間で変換。2 の補数表示付き。