Unix Timestamp 変換
秒・ミリ秒を自動判定、UTC/JST/任意タイムゾーンで双方向変換。貼り付けるだけで動きます。
— — 単一時刻変換
— オフセット: — 履歴
期間計算
開始と終了を入れて、ミリ秒から日までの差分を同時に確認できます。
期間の計算
— — — — — 使い方
- 変換したい値を上の入力欄に貼り付けます。10桁以下なら秒、11〜13桁ならミリ秒、14〜16桁ならマイクロ秒、17桁以上はナノ秒として自動判定されます。秒/ミリ秒の切替を手で迷う必要はありません。
- 日時側を編集すれば、Unix Timestamp 側も同期して更新されます。逆もまた同じ。どちらが「入力」か「出力」かを気にせず、双方向に動きます。
-
表示するタイムゾーンは
UTC / JST / 任意のタイムゾーンから選択できます。タイムゾーンを切り替えても Unix Timestamp の値そのものは変わらず、「同じ瞬間を別の見え方で表示する」だけです。 - URL に現在の値が自動で反映されているので、その URL をそのままチャットや Issue に貼れば、相手も同じ値で開けます。
- 下にある区間計算機を使うと、2つの日時を選んで「何秒・何分・何時間・何日離れているか」をまとめて確認できます。SLA の経過時間や、ログの時刻差を出すときに便利です。
こんな時に使えます
ログの時刻を読みたい
AWS CloudWatch や Stackdriver のログに含まれる Unix Timestamp を、JST の人間に読める時刻にサッと変換できます。秒/ミリ秒の判定間違いで「2055年のイベント?」みたいな事故が起きません。
API のテストデータ作成
curl や Postman で API を叩くときの expires_at や created_at 用の値が、ピンポイントの日時から1秒で出ます。コピーボタンで即貼り付け可能。
障害時のタイムライン整理
障害報告書を書くとき、複数システムのログから Unix Timestamp を抜いて時刻を揃えると、起こった順番が分かりやすくなります。区間計算機で「事象 A から事象 B まで何分」も即出ます。
JWT のデバッグ
JWT の iat / exp / nbf は Unix Timestamp (秒) です。「このトークン本当に期限切れ？」を秒で確認できます。
仕様のポイント
- 桁数から単位を自動推定: 10桁以下 → 秒、11〜13桁 → ミリ秒、14〜16桁 → マイクロ秒、17桁以上 → ナノ秒。マイクロ/ナノはミリ秒精度に丸めて扱います (1ms以下の精度が必要な場合は別ツールで)。
- 負の値も扱えます: 1970年以前の日時として表示。古いマイグレーション用の epoch 計算でも安心です。
- 2038年問題は対象外: ブラウザの JavaScript は 64bit の浮動小数で日時を扱うため、2038年以降の値も問題なく変換できます。32bit 環境固有の制約は本ツールには該当しません。
- うるう秒は JavaScript の Date 実装に準拠: 23:59:60 のような表記は実装依存で翌日 00:00 に吸収されることがあります。秒精度の検証用途では、別の処理系と二重チェックを推奨します。
- すべてブラウザ内で完結: 入力した値はサーバーに送信されません。社外秘のタイムスタンプを貼って変換しても、外に出ない設計です。
もっと詳しく：Unix Timestamp の落とし穴
2038年問題（32bit のオーバーフロー）
Unix Timestamp を 32bit 符号付き整数（time_t）で持つシステムでは、2038年1月19日 03:14:07 UTC を超えた瞬間に値が桁あふれし、1901年へ巻き戻ってしまいます。これがいわゆる 2038年問題です。古い C 製プログラムや組み込み機器、一部データベースの timestamp 型が影響を受けます。一方、64bit 整数に拡張した環境や、ブラウザの JavaScript（内部は 64bit 浮動小数）では問題になりません。本ツールも 2038年以降の値を普通に変換できます。
うるう秒は値として存在しない
Unix Timestamp は「1日 = 86,400秒」固定で数える仕様で、実際の UTC に挿入されるうるう秒を値として持ちません。うるう秒の瞬間は同じ秒値が繰り返される（または飛ばされる）扱いになります。Google などは「UTC smear」と呼ぶ方式で、うるう秒の前後 24 時間に時間を薄く引き伸ばして辻褄を合わせています。秒単位の厳密な検証では、この前提を頭に入れておくと混乱しません。
秒・ミリ秒・ナノ秒が混在する現場
同じ「Unix 時間」でも、扱う単位は環境でバラバラです。Linux の date +%s は秒（10桁）、JavaScript の Date.now() はミリ秒（13桁）、Java の Instant や Go の一部 API はナノ秒まで扱います。桁を取り違えると「2055年のイベント？」のような事故が起こります。本ツールが桁数から単位を自動判定するのは、この取り違えを防ぐためです。
関連ツール
他にもいくつかの単機能ツールを揃えています。
- JSON整形 — JSONを整形・圧縮・検証。エラー位置を行番号/列で指摘。
- 文字数カウント — 文字数・バイト数・行数・Twitter文字数を即時カウント。絵文字対応。
- B2クラウド 使えない文字チェッカー — ヤマトB2クラウドで弾かれる機種依存文字・囲み数字などを即時検出し、推奨置換を提示。
- PDF 結合・分割 — PDFの結合・分割・ページ並び替え・回転をブラウザ内で完結。アップロード不要・サーバーに送信しません。
よくある質問
Unix Timestamp とは何ですか？
秒とミリ秒、どちらを使うべきですか？
16桁・19桁を入れたら警告が出るのはなぜ？
JST の Unix Timestamp はありますか？
1970年以前（負の値）も扱えますか？
2038年問題は大丈夫？
うるう秒はどう扱いますか？
23:59:60 のような表記を入れると、実装依存で翌日 00:00 に吸収されるケースがあります。