UNIXタイム変換｜秒・ミリ秒の自動判別と日本時間の同時表示（無料）

ログに並ぶ 1787500800 という数字。データベースに入っている 1787500800000。どちらもUNIXタイムですが、片方は秒、もう片方はミリ秒です。ここを取り違えると、1970年や5万年後の日付が出てきます。

このツールは、桁数から秒・ミリ秒・マイクロ秒を自動で判別し、日本時間とUTCを同時に表示します。逆方向（日時からUNIXタイム）にも対応し、曜日と「今から何日前か」も出します。現在のUNIXタイムは1秒ごとに更新されます。

処理はすべてブラウザ内で完結し、入力した値は送信されません。

UNIXタイムとは、1970年からの秒数

UNIXタイム（エポック秒）は、1970年1月1日 0時0分0秒（UTC）から数えた経過秒数です。タイムゾーンも夏時間も含まない、ただの数値です。

この単純さが利点になります。

だからこそ、ログ、データベース、APIの内部では日時をUNIXタイムで持ち、人に見せるときだけ変換するという設計が一般的です。「保存は数値、表示はローカル時間」と覚えておくと、時差にまつわる不具合の大半を避けられます。

桁数で、単位を見分ける

単位の取り違えは、実務で最も多いミスです。桁数を見れば判別できます。

言語によって既定の単位が違うのも、混乱の原因です。

JavaScriptとPHPの間でデータをやり取りするときに、1000倍の食い違いが起きるのはこのためです。境界をまたぐ場所では、単位を明示的に変換してください。

日本時間とUTCは、9時間ずれている

日本には夏時間がないため、年間を通じて常に+9時間です。この点は、夏時間のある国を相手にするシステムより単純です。

ただし注意点があります。日付が変わる境界です。日本時間の8月23日 午前8時は、UTCでは8月22日 23時です。「日付ごとの集計」をUTC基準で行うと、日本の感覚とは1日ずれた区切りになります。アクセス解析やレポートの数字が合わない原因が、ここにあることは少なくありません。

2038年問題は、まだ終わっていない

UNIXタイムを32ビットの符号付き整数で保持しているシステムは、2038年1月19日3時14分7秒（UTC）を超えると値があふれ、1901年に戻ります。

現在の主要なOSや言語は64ビットに移行済みですが、古い組み込み機器、レガシーなデータベースの列定義、独自形式のバイナリファイルには残っています。手元のシステムで確認したい場合は、2038年1月20日の日時を入れてみて、正しく扱えるかを試すのが手早い方法です。サポート期限の考え方はサポート期限（EOL）とはにまとめています。

実務でUNIXタイムを扱うときの原則

4番目は見落とされがちです。誕生日や締切日のような「日付そのもの」を、UNIXタイムとして0時0分で保存すると、タイムゾーンの違う環境で前日になります。日付は文字列（2026-08-23）として持つのが安全です。

よく使う期間を、秒数で覚えておく

UNIXタイムは秒数なので、期間の計算は足し算と引き算だけで済みます。よく使う値を控えておくと、電卓を叩かずに判断できます。

日時の処理で踏みやすい落とし穴

UNIXタイムに出会う場所

とくにJWTの exp（有効期限）は、「トークンが切れているのか、それとも別の原因なのか」を判断するときに必ず見る値です。桁数は10桁（秒）で、現在時刻より小さければ期限切れです。

「1970年1月1日」が表示されたときの意味

画面やログに1970年1月1日が出るのは、ほぼ次のどれかです。バグの手がかりになります。

いずれも「日時が入っていない」ことのサインです。1970年は日付の異常値だと覚えておくと、原因の切り分けが早くなります。