UNIX時間とは何か｜日時に変換する3つの方法と、秒・ミリ秒・時差の間違えやすい点

UNIX時間とは

UNIX時間（Unixタイムスタンプ、エポック秒、epoch time とも呼ばれます）とは、協定世界時（UTC）の1970年1月1日0時0分0秒を起点として、そこから何秒たったかを数えた1本の整数です。たとえば 1700000000 という値は、UTCで2023年11月14日22時13分20秒、日本時間（JST）で2023年11月15日7時13分20秒を指します。「2023/11/15 07:13:20」のような表記とまったく同じ瞬間を、数字1個で言い表したものだと考えてください。

起点になっている1970年1月1日は「エポック（epoch）」と呼ばれます。この日付に宇宙的な意味はなく、UNIXというOSが開発されていた時期に近く、かつ切りのよい年の元日だったという実務的な理由で選ばれたものです。重要なのは起点の年ではなく、世界中のどの環境でも同じ起点・同じ刻み方を使っている、という合意そのものです。

では、人間に読みやすい「2026年10月4日 8時30分」という形ではなく、なぜわざわざ数値で持つのでしょうか。理由は4つあります。

• 計算ができる … 2つの時刻の差を知りたいとき、単に引き算すればよい。文字列の日時では「月の日数が月によって違う」「年をまたぐ」「うるう年がある」をすべて自分で面倒を見る必要がある。
• 並べ替えができる … 数値の大小がそのまま時間の前後になる。文字列だと「2026/9/5」と「2026/10/4」を辞書順に並べたときに9月が後ろに来てしまう、という事故が起きる。
• タイムゾーンを持たない … 値そのものは常にUTC基準の経過秒数なので、保存した時点で地域の情報が混ざらない。日本で記録した値をアメリカで読んでも、指している瞬間は1つに決まる。
• 表記の違いに巻き込まれない … 「2026-10-04」「10/04/2026」「令和8年10月4日」のような書式のゆれ、区切り記号の違い、全角半角の違いが、そもそも発生しない。

この4つの性質から、UNIX時間はデータベースの保存値、APIのレスポンス、サーバーのログ、認証トークンの有効期限（JWTの `exp` や `iat`）、ファイルの更新時刻など、「プログラムが内部で時刻を持ち回る」場所のほぼ標準形になっています。逆に、画面に出す段階では必ず人間が読める形へ変換します。つまりUNIX時間は保存と計算のための形式で、表示のための形式ではありません。

刻み方について1点だけ補足します。UNIX時間は、1日を常に86400秒（24×60×60）として数えます。現実の時刻には、地球の自転の揺らぎを合わせるために「うるう秒」がまれに挿入されますが、UNIX時間の一般的な実装はこれを無視します。そのため、厳密な天文時刻との間にはごく小さなずれが残ります。業務システムで問題になる水準ではありませんが、「1秒も違わない」とは言えない、という点は覚えておいてください。本ツールもこの一般的な方式に従っており、うるう秒は考慮していません。

UNIX時間を日時に変換する3つの方法

実務でUNIX時間を日時に戻したい場面は、だいたい3通りに分かれます。「いま目の前のログに出ている1個の値をすぐ知りたい」「表に入った何百件をまとめて読みたい」「プログラムの中で変換したい」。それぞれに向いた方法を順に説明します。

1つ目は、本ツールのような変換ツールを使う方法です。1件〜数件を手早く確かめたいときは、これがいちばん速い選択です。画面は上下2段に分かれています。上段の「Unix時間 → 日時」にタイムスタンプの数値を貼り付けると、ISO 8601形式・UTC・日本時間（JST）の3つが同時に表示されます。単位は桁数から秒かミリ秒かを自動判定し、その判定結果を欄の下に明記しますが、「秒」「ミリ秒」のボタンで手動に切り替えることもできます。下段の「日時 → Unix時間」は逆向きで、日時を選ぶとUnix秒とUnixミリ秒が並びます。どちらにも「現在時刻を使う」ボタンがあるので、いまの時刻のタイムスタンプを知りたいだけのときも使えます。入力値はブラウザ内だけで処理し、当サイトのサーバーへは送信していません。

2つ目は、Excel・Googleスプレッドシートの数式です。CSVで受け取ったログや、データベースから書き出した表のように、UNIX時間の列が何百行も並んでいる場合は、表計算ソフトで一括変換するのが現実的です。A1セルにUNIX秒が入っているとして、次のように書きます。

• UTCの日時にする … `=(A1/86400)+DATE(1970,1,1)`（86400で割って「日数」に直し、1970年1月1日の日付に足している）
• 日本時間（JST）にする … `=(A1/86400)+DATE(1970,1,1)+9/24`（UTCに9時間ぶん、つまり9/24日を足す）
• 値がミリ秒（13桁）のとき … `=(A1/86400000)+DATE(1970,1,1)+9/24`（割る数を1000倍にする）
• 日時からUNIX秒に戻す … `=(A1-DATE(1970,1,1))*86400`（A1に日時が入っている場合。JSTの日時なら結果から32400を引くとUTC基準になる）

数式を入れた直後は「45934.3」のような小数が表示されます。これは正しい結果で、Excelが日時を「1900年からの日数＋1日の中の割合」という数値で持っているためです。セルの表示形式を「日付」や「ユーザー定義: yyyy/mm/dd hh:mm:ss」に変えれば、読める形になります。ここでよくある取り違えが、時差の足し忘れです。`+9/24` を書かずにそのまま使うと、全行が9時間前の表示になります。9時間なら「なんとなく合っている」ように見えてしまうため、日付の切り替わりをまたぐ行（午前0時〜9時に起きたできごと）だけ日付が1日ずれる、という形で後から発覚しがちです。1行ぶんを本ツールで変換して突き合わせ、JSTの値が一致することを確かめてから全行に適用してください。

3つ目は、プログラムの標準関数です。変換を処理の一部に組み込むなら、自分で86400を掛けたり割ったりせず、言語が用意している関数を使ってください。以下はいずれも標準機能で、追加のライブラリは要りません。括弧内は逆向き（日時からUNIX時間）の取り方です。

JavaScript は `new Date(1700000000 * 1000)` でDateオブジェクトになります。引数がミリ秒なので、秒の値には1000を掛ける必要があります（`Date.now()` は現在のミリ秒、`Math.floor(Date.now() / 1000)` が現在の秒）。Python は `datetime.fromtimestamp(1700000000, tz=timezone.utc)` でUTCの日時になります。`tz` を省略すると実行環境のローカル時刻として解釈されるため、意図がはっきりするよう明示するのが安全です（`int(datetime.now(timezone.utc).timestamp())` が現在の秒）。

PHP は `date('Y-m-d H:i:s', 1700000000)` で文字列になりますが、表示はPHP側のタイムゾーン設定（`date.timezone`）に従うため、設定値を確認しておいてください（`time()` が現在の秒）。MySQL は `SELECT FROM_UNIXTIME(1700000000);` で、結果は接続のタイムゾーンに従います（`UNIX_TIMESTAMP()` が現在の秒）。Java は `Instant.ofEpochSecond(1700000000)` でUTCの瞬間を表すInstantになり、`.atZone(ZoneId.of("Asia/Tokyo"))` で日本時間の表記へ変換できます（`Instant.now().getEpochSecond()` が現在の秒）。Linux・macOSのコマンドラインなら `date -d @1700000000`（GNU系）、`date -r 1700000000`（BSD系・macOS）が使えます（`date +%s` が現在の秒）。

3つの方法のうちどれを選ぶかは、件数と繰り返しの有無で決めるのが分かりやすいです。1件なら変換ツール、数十件以上の一括なら表計算ソフト、毎回同じ変換が発生するなら標準関数でコードに書く。そして、どの方法を使う場合でも、最初の1件は別の方法でも変換して値が一致するかを見ておくと、時差や単位の取り違えを入り口で止められます。

秒・ミリ秒・タイムゾーンで間違えやすい点

UNIX時間でつまずく原因は、ほぼ3種類に集約されます。単位（秒かミリ秒か）、タイムゾーン（UTCかJSTか）、そして桁あふれです。順に見ていきます。

もっとも多いのが単位の取り違えです。UNIX時間は秒で数えるのが基本ですが、ミリ秒（1000倍した値）で扱う環境もかなりあります。JavaScriptの `Date.now()`、Javaの `System.currentTimeMillis()`、多くのJavaScript製APIはミリ秒を返します。一方でPHPの `time()`、Linuxの `date +%s`、JWTの `exp`、多くのデータベースは秒です。見分け方は桁数です。現在に近い時刻であれば、秒は10桁、ミリ秒は13桁になります。この見分けを間違えると、結果は中途半端にずれるのではなく、まったく違う年になります。ミリ秒の値を秒として解釈すれば数万年先の日付になり、秒の値をミリ秒として解釈すれば1970年1月の数日目になります。「西暦56000年」や「1970年1月20日」が出たら、計算が壊れたのではなく単位を取り違えただけです。本ツールは1兆（1e12）を境に自動判定しますが、1970年前後のごく小さい値や極端な未来の値では判定が外れることがあるため、そのときは「秒」「ミリ秒」のボタンで手動指定してください。

なお、刻みはミリ秒より細かいものも存在します。マイクロ秒（16桁、Pythonの `time.time_ns() // 1000` など）、ナノ秒（19桁、Go言語の `UnixNano()` など）です。16桁や19桁の値に出会ったときは、必要な桁数だけ末尾を落として秒やミリ秒に直してから変換してください。本ツールが受け付けるのは秒とミリ秒の2つです。

2つ目はタイムゾーンです。UNIX時間そのものは常にUTC基準なので、値のほうに時差の問題はありません。問題が起きるのは必ず「表示に直すとき」と「日時から値を作るとき」です。日本標準時（JST）はUTCより9時間進んでいるため、同じ瞬間でもUTC表記とJST表記は9時間ずれます。UTCの2023年11月14日22時13分20秒は、JSTでは2023年11月15日7時13分20秒です。ここで厄介なのは、9時間というずれが「明らかに変」には見えないことです。ログの時刻が9時間ずれていても、業務時間帯の記録なら違和感なく読めてしまい、日付をまたぐ時間帯の記録だけが1日ずれて、後から整合が取れなくなります。本ツールはUTCとJSTを常に並べて表示するので、手元の値がどちらの基準なのかをその場で突き合わせられます。

逆向きの「日時 → Unix時間」で注意が要るのは、入力した日時がどのタイムゾーンの時刻として解釈されるかです。本ツールの下段は、ブラウザが動いているその端末のローカルタイムゾーンで解釈します。日本国内の端末であればJSTとして扱われますが、海外のパソコンや、タイムゾーン設定を変えている端末では結果が変わります。これは本ツールに限った話ではなく、Excelの `DATE()` や各言語の「ローカル時刻」系の関数でも同じです。自分の環境の設定が何になっているかを一度確かめておくと、原因の分からないずれに悩まされません。日本にはいま夏時間（サマータイム）がないため実務では常に+9時間と同じ結果になりますが、海外の時刻を扱う場合は夏時間の切り替わりで1時間ずれる期間があることも頭に入れておいてください。

3つ目は桁あふれです。UNIX時間を32ビットの符号付き整数で持つ環境では、表せる上限が 2147483647 で、これはUTCの2038年1月19日3時14分7秒にあたります。この瞬間を超えると値が負に回り込み、1901年あたりの日付として解釈されてしまいます。これが「2038年問題」です。いまの64ビット環境では約3000億年先まで表せるため実務上の心配はありませんが、古い組み込み機器、長く更新されていない業務システム、32ビット環境のデータベース列では現在も起こり得ます。期限や有効期間を未来の日付で持つ処理（証明書・ライセンス・長期の予約データ）は、2038年を越える値を1件入れて動作を確かめておくと安心です。

最後に、調べた値を記録に残すときの作法です。社内で時刻をやり取りするときは、UNIX時間のままではなく、ISO 8601形式（`2023-11-14T22:13:20Z` のように末尾のZでUTCを示す、または `2023-11-15T07:13:20+09:00` のように時差を明記する形）に直して書いてください。「2023/11/15 07:13」のように時差を書かない形は、読む人の環境によって意味が変わる余地が残ります。本ツールが上段でISO 8601を表示し、コピーボタンを置いているのはこのためです。値を貼るときは、単位（秒かミリ秒か）と基準（UTCかJSTか）を一緒に書き添えるだけで、後から読む人の確認作業が丸ごと消えます。

よくある質問