UNIX時間変換

UNIX時間変換の使い方

1. 1Unix時間またはカレンダー日時を入力します
2. 2自動で相互変換された結果が表示されます
3. 3変換結果をコピーして利用します

UNIX時間変換の例文・サンプル

1700000000

2024-01-01 12:00:00

良いUNIX時間変換の判断基準

APIレスポンスやログに出てくる数字の時刻（UNIXタイムスタンプ）を読み解くときや、日時からタイムスタンプを作るときに使います。変換結果を使う前に、下の基準で確認します。

• 秒単位かミリ秒単位かを確認したか

  UNIX時間は秒単位が基本ですが、JavaScriptのDate.now()などはミリ秒単位を返します。現在に近い時刻なら秒は10桁・ミリ秒は13桁が目安で、桁数を見れば取り違えに気づけます。

• 変換結果の表示タイムゾーンを確認したか

  UNIX時間そのものはタイムゾーンを持たず、世界共通の1つの値です。それを人間が読む日時に直すときに初めてJSTかUTCかが問題になります。表示された日時がどちらの基準かを必ず確認します。

• 元データの基準タイムゾーンを把握しているか

  「ログの日時表記がUTCで書かれていた」「DBの日時カラムがJSTだった」など、変換元の日時文字列がどの基準かで結果が9時間変わります。データの仕様を確認してから変換します。

• 変換結果の年・日付が常識的か確認したか

  変換結果が1970年に近すぎたり、数百年先になっていたりしたら、単位の取り違えや桁の欠けを疑います。「だいたい今ごろの日時になるはず」という感覚チェックを挟みます。

• 時差の加算を二重にしていないか

  ツールがすでにJSTで表示しているのに、さらに自分で9時間足すと二重加算になります。表示の基準を確認したら、それ以上の手計算は加えません。

• 古いシステムでは2038年問題を意識したか

  32bitの符号付き整数でUNIX時間を扱うシステムは、2038年1月にオーバーフローします。レガシーシステムで遠い将来の日時を扱う場合は、この制約を意識して確認します。

ありがちな失敗例（NG → 改善）

数字だけの時刻を人が読める日時に直す

Unix タイムスタンプ（UNIX時間・エポック秒）は、コンピューターシステムで広く使われる日時表現で、1970年1月1日 00:00:00 UTC からの経過秒数で表されます。データベース・ログファイル・API レスポンス・JWT などで頻繁に登場しますが、人間が直接読み解くのは困難です。本ツールは Unix タイムスタンプ ⇔ 通常の日時表記の双方向変換を行い、デバッグ・データ分析・システム連携の現場で日常的に使えます。

画面にあるのは「UNIXタイムスタンプまたは日時」の入力欄1つだけです。数字を入れると日時に、日時の文字列を入れるとタイムスタンプに、入力の形で自動的に方向が切り替わります。出力には日本時間と世界標準時の2つの表記に加えて、現在のタイムスタンプと現在の日時も併記されます。以下では、編集部が実際に6パターンを入れて、返ってきた表示をそのまま載せます。

DB の日時カラム・API レスポンス・ログ調査で使う場面

【1. データベース日時カラムの確認】MySQL や PostgreSQL でタイムスタンプ型の値を見た時、人間が読める日時に変換できます。

【2. API レスポンスのデバッグ】API が返す created_at: 1714521600 のような値が、すぐ人の読める日時で分かります。

【3. ログ解析】サーバーログに記録された Unix タイムスタンプを、調査時刻に合わせて変換できます。

どれも、数字を1つ貼って意味を確かめる使い方です。だからこそ、貼った数字がどう解釈されたのかを取り違えると、そのまま報告書や障害対応に流れ込みます。次の項目からは、桁数の違い・境界の値・書式の違いを入れたときに、画面が実際に何を返したかを並べます。

1700000000・0・13桁のミリ秒を入れた実処理結果

1つ目は10桁のタイムスタンプです。

入力: 1700000000 出力: 入力: 1700000000 (UNIXタイムスタンプ) と表示され、日時 (JST): 2023/11/15 07:13:20、日時 (UTC): 2023-11-14T22:13:20.000Z

2つ目は 0 です。

入力: 0 出力: 日時 (JST): 1970/01/01 09:00:00、日時 (UTC): 1970-01-01T00:00:00.000Z

世界標準時の0時が、日本時間では9時と表示されました。この9時間の差が、そのまま時差です。

3つ目は13桁です。

入力: 1700000000000 出力: 日時 (JST): 2023/11/15 07:13:20、日時 (UTC): 2023-11-14T22:13:20.000Z

10桁のときと同じ日時になりました。13桁の数字は自動的にミリ秒として扱われ、1000で割ってから変換されています。手元で先に1000で割ってから貼る必要はありません。

どの結果にも、末尾に現在のタイムスタンプと現在の日時 (JST) の行が付きます（この値は実行した時点のものです）。

2147483647 と全角数字を入れた実処理結果

4つ目は、いわゆる2038年問題の境界にあたる値です。

入力: 2147483647 出力: 日時 (JST): 2038/01/19 12:14:07、日時 (UTC): 2038-01-19T03:14:07.000Z

エラーにはならず、そのまま変換されました。32ビットの整数で時刻を持つ古いシステムではここが上限になりますが、ブラウザ側の日時の扱いにはその制限が無いため、本ツールでは境界を越えた値も表示できます。逆に言えば、ここで表示できたことは、受け渡す先のシステムで扱える保証にはなりません。

5つ目は全角数字です。

入力: １７００００００００ 出力: エラー「「１７００００００００」を日付として認識できません。 例: 2024-01-01 12:00:00 または 1700000000」

全角のまま入れると半角に直してもらえず、そのままエラーになります。資料や社内チャットからコピーした数字が全角になっていることは珍しくないので、エラーが出たらまず全角と半角を疑ってください。

マイナス1000 と打つと西暦1000年が返るクセと弱点

6つ目が、いちばん分かりにくい結果でした。

入力: -1000 出力: 入力: -1000 (日時) と表示され、UNIXタイムスタンプ: -30610257539、UNIXタイムスタンプ (ミリ秒): -30610257539000

数字を入れたのに、括弧の中が「日時」になっています。タイムスタンプかどうかの判定に使う条件が半角数字1桁から13桁で、先頭のマイナス符号を許していないため、日時の文字列として解釈する側に回りました。-1000 は日時としては西暦1000年1月1日と読まれ、そこから逆算した値が返っています（コードを追い、-1000 を日時として解釈すると1000年1月1日になることを確認しています）。1000秒前のつもりで打つと、まったく無関係な年の値が出ます。

弱点は2つです。1つ目は、1970年より前を指す負のタイムスタンプを、そのままでは変換できないこと。2つ目は、全角数字を半角に直してくれないことです。同じサイトの日付計算ツールは全角を半角に直す処理を持っていますが、このツールには入っていません。

今回試したのは6パターンで、この範囲では表示が崩れることはありませんでした。ただしこれは6パターンで見えた範囲であり、どんな入力でも意図どおりに判定される保証ではありません。

UNIX 時間変換に向かない用途と、読み違えやすい点

1つ目の失敗は、ミリ秒単位とのまちがいです。Unix タイムスタンプは秒単位ですが、JavaScript の Date.now() はミリ秒単位を返します。1000倍違う場合は、ミリ秒と秒を取り違えていないか確認してください。

2つ目は、タイムゾーンの取り扱いです。Unix タイムスタンプは UTC 基準で、JST に変換するには +9時間を足します。本ツールは JST 表示も提供しますが、ログ・データの基準がどのタイムゾーンか必ず確認してください。

3つ目は、2038年問題です。32bit 符号付き整数の Unix タイムスタンプは2038年1月19日にオーバーフローします。レガシーシステムを扱う場合は意識してください。実測では境界の値でもエラーが出なかったため、古いシステム側の制約は本ツールの画面には現れません。

向かないのは、監査や法務で使う時刻の証明、締め日や請求の確定計算、そして複数拠点のタイムゾーンをまたぐ運用の設計です。表示は日本時間と世界標準時の2つに限られ、ほかの地域の時刻は出ません。

datetime ライブラリや Excel との使い分け

プログラミング言語の datetime ライブラリでも変換可能ですが、コードを書く手間があります。Excel の関数も使えますが、タイムゾーン処理が複雑です。本ツールはブラウザ内で完結し、JST/UTC 両方の表示ですぐ変換できます。会員登録もログインも不要です。

実測を踏まえた使い分けはこうなります。ログや API レスポンスに出てきた1つの数字の意味を今すぐ知りたい、桁数が秒かミリ秒かを見分けたい、という場面は本ツールが速い。負の値を扱う、ほかの地域のタイムゾーンに変換する、数百行の時刻の列をまとめて処理する、という作業はライブラリや表計算が向きます。特に負の値は、実測のとおり別の解釈に回るため、本ツールでは扱えません。

変換した日時を報告や資料に書く前に確認する3点

1つ目は桁数です。10桁なら秒、13桁ならミリ秒として自動で処理されました。自分で先に1000で割ってから貼ると、二重に割ることになります。

2つ目は、日本時間と世界標準時のどちらの行を引用しているかです。出力には両方が並びます。0 を入れた例のように、同じ値でも表示は9時間ずれます。報告書に貼るときは、どちらの基準かを1行添えてください。

3つ目は、括弧の中の表示です。数字を入れたのに (日時) と出ていたら、マイナス1000 の例と同じで、タイムスタンプとして判定されていません。その場合の結果は、期待した意味とは別物です。

この3点は、6パターンの実測から見えた事実に沿って並べています。元のデータがどの基準で記録されているかは、データ側の仕様を見て判断してください。