Unixタイムスタンプとは｜秒とミリ秒の違い・2038年問題・日時変換の実務ガイド
公開日：2026年7月25日 対象ツール：Unixタイムスタンプ変換
ログやAPIのレスポンスで 1700000000 のような数字を見て、これが時刻だと言われても直感的にはピンと来ません。この記事では、単なる操作説明ではなく「なぜこの数字が時刻になるのか」という仕組みから、現場でつまずきやすい落とし穴までを整理します。手を動かしたくなったら本ツールで実際に変換しながら読んでください。
Unixタイムスタンプという発想
Unixタイムスタンプ（エポック秒、Unix time）は、1970年1月1日0時0分0秒（UTC）を0地点とし、そこから何秒経ったかという1本の整数だけで時刻を表す方式です。年・月・日・時・分・秒に分けず、地域も暦も持ち込まない「経過秒数」に振り切っているのが要点です。この単純さのおかげで、比較（大小＝前後）も差分（引き算＝経過時間）も四則演算で済み、どの国のサーバーでも同じ値になります。人間には読みにくい代わりに、機械には極めて扱いやすい表現なのです。
どこで使われているか
この形式は身の回りのあらゆる場所に潜んでいます。
- サーバーログ：アクセスログやエラーログの記録時刻。
- データベース：作成日時・更新日時をINT型で保持する設計。
- API：トークンの有効期限（exp）やイベント発生時刻の受け渡し。
- ファイル：更新日時（mtime）などファイルシステム上のタイムスタンプ。
いずれも「地域差なく1つの数字で表せる」利点を活かした使い方です。
秒とミリ秒の違い（最頻出のミス）
最もハマりやすいのが単位の取り違えです。多くの言語で秒が基本ですが、JavaScriptの Date.now() などはミリ秒（1秒＝1000ミリ秒）を返します。秒は10桁、ミリ秒は13桁が現在の目安で、秒を1000倍すればミリ秒になります（例：1700000000 → 1700000000000）。見分け方はシンプルで、桁数を数えるだけ。13桁の値を秒として渡すと約1000倍先の遠い未来になり、逆に10桁をミリ秒扱いすると1970年直後に張り付きます。「日時が桁違いにずれた」ときは、まず単位を疑ってください。
タイムゾーンとUTC／ローカル
タイムスタンプ自体はUTC基準の絶対時刻で、タイムゾーン情報を持ちません。ずれが生まれるのは、それを人間向けに表示する段階です。同じ 1700000000 でも、UTCでは2023年11月14日22:13:20、日本のローカル時刻（JST＝UTC+9）では翌15日7:13:20と表記が変わります。数値は同じ一瞬を指しているのに表示だけが違う、という関係を押さえておくと混乱しません。ISO 8601のZ付き表記（末尾のZはUTCの意味）も、この絶対時刻を明示する書き方です。
2038年問題とうるう秒
秒を 32ビット符号付き整数で持つ古いシステムでは、2038年1月19日3:14:07 UTCで上限に達し、次の秒で負にあふれて時刻が壊れます。これが2038年問題です。対策は64ビット化で、現代の環境なら実害は基本的にありませんが、レガシーなDBカラムや組み込み機器では今も注意が要ります。また、実際の1日は微妙に長さが揺れるため天文学的には「うるう秒」が挿入されますが、Unixタイムスタンプはうるう秒を数えず1日を常に86400秒として扱うのが慣例です。秒単位の厳密性が要る領域を除けば、通常はこの前提で問題ありません。
ありがちな失敗例
- ミリ秒の値を秒のAPIに渡し、有効期限が数万年先になって検証が素通りする。
- UTCで保存した値をローカルとして表示し、9時間ずれたまま気づかない。
- 秒とミリ秒が混在したログを差分計算し、経過時間が1000倍でおかしくなる。
いずれも「単位」と「基準（UTCかローカルか）」の2点を確認すれば防げます。
このツールでの変換方法
本ツールは上記の確認を一画面で行えます。「タイムスタンプ→日時」で単位（秒・ミリ秒）を選んで数値を入れると、ローカル・UTC・ISO 8601の3通りが同時に出るので、単位ずれもTZずれも一目で見抜けます。逆に「日時→タイムスタンプ」なら秒とミリ秒の両方を同時に取得でき、「現在時刻」ボタンで今の値もすぐ入ります。負の値（1970年以前）や2038年以降も計算できます。ログ調査や開発の手元の道具としてご活用ください。