Unix時間（エポック秒）とは？仕組みと読み方

Unix時間は「1970年1月1日0時（UTC）からの経過秒数」

Unix時間（UNIXタイムスタンプ、エポック秒とも呼ばれます）は、協定世界時（UTC）の1970年1月1日0時0分0秒を0とし、そこから何秒たったかを1つの整数で表したものです。この起点の瞬間を「エポック」と呼びます。

たとえば2026年10月23日0時0分0秒（UTC）のUnix時間は1792713600です。1日は86,400秒なので、この数を86,400で割ると20,749日となり、エポックからちょうど20,749日たっていることがわかります。起点より前の時刻は負の数で表し、1969年12月31日23時59分59秒（UTC）は−1です。

日付を「年・月・日・時・分・秒」に分けて持つ代わりに、ただの通し番号として扱えるのが最大の特徴です。2つの時刻の差は引き算するだけで秒数として求まり、並べ替えや比較も数値の大小で済みます。この扱いやすさから、OS、データベース、プログラミング言語、Web APIなどで広く使われています。

なお、Unix時間はうるう秒を数えません。どの日も86,400秒ちょうどとして扱うため、厳密にはUTCの経過秒数とわずかにずれますが、日常的な日時の変換ではこの点を意識する必要はほとんどありません。

• 0 … 1970年1月1日 0:00:00（UTC）＝ 日本時間 9:00:00
• 1000000000 … 2001年9月9日 1:46:40（UTC）
• 1700000000 … 2023年11月14日 22:13:20（UTC）＝ 日本時間 11月15日 7:13:20
• 1792713600 … 2026年10月23日 0:00:00（UTC）

秒（10桁）とミリ秒（13桁）の見分け方

Unix時間には、秒単位のものとミリ秒単位のものが混在しています。たとえばJavaScriptのDate.now()はミリ秒、多くのWeb APIやデータベースの関数は秒を返します。同じ時刻でも、秒なら1792713600、ミリ秒なら1792713600000と、1000倍の差があります。

見分けるいちばん簡単な目安は桁数です。2001年9月9日から2286年11月20日ごろまでの時刻は、秒なら10桁、ミリ秒なら13桁になります。現在の日時を扱っている限り、10桁なら秒、13桁ならミリ秒と考えてほぼ間違いありません。マイクロ秒（16桁）やナノ秒（19桁）で記録するシステムもあるので、それ以上の桁数なら単位の仕様を確認しましょう。

単位を取り違えると、結果は極端にずれます。ミリ秒の1792713600を秒として読むと2026年ですが、逆に秒の値1792713600をミリ秒として読むと、1970年1月21日9時12分57.6秒（UTC）という起点直後の日付になります。反対に、ミリ秒の値をそのまま秒として扱うと、西暦5万年を超える遠い未来の日付になります。変換結果が1970年付近や桁外れの未来になったら、まず単位を疑ってください。

日本時間（JST）との9時間差に注意する

Unix時間そのものにはタイムゾーンがありません。世界中どこで記録しても、同じ瞬間なら同じ数値になります。タイムゾーンが関係するのは、その数値を「何年何月何日何時」という人が読む形に直すときです。

日本標準時（JST）はUTCより9時間進んでおり、サマータイムもありません。そのため、Unix時間0はUTCでは1970年1月1日0時ですが、日本時間では同じ日の9時です。逆に日本時間で日付を指定してUnix時間を求めるときは、UTCに直すために9時間を差し引きます。

具体例で確認します。日本時間の2026年10月23日0時0分は、UTCでは前日の10月22日15時0分にあたり、Unix時間は1792681200です。UTCの10月23日0時（1792713600）と比べると、ちょうど9時間分の32,400秒小さくなります。日本時間の10月23日9時30分なら1792715400です。

実務でよくある失敗が、「2026-10-23」のような日付だけの値をUnix時間にするときの基準のずれです。UTCの0時とみなすか日本時間の0時とみなすかで9時間変わり、日本時間の朝9時より前のデータが前日に分類されるといった集計のずれにつながります。日付だけを扱うときも、どのタイムゾーンの0時なのかを決めておくことが大切です。

ログやAPIで見かけるUnix時間の読み方

Unix時間は、サーバーのアクセスログ、APIのレスポンス、トークンの有効期限、データベースの作成日時など、さまざまな場所で使われます。たとえばAPIのレスポンスに「created: 1700000000」とあれば、そのデータはUTCの2023年11月14日22時13分20秒、日本時間では11月15日7時13分20秒に作られたと読み取れます。

有効期限の確認にも便利です。発行時刻が1792681200（日本時間2026年10月23日0時）で、有効期限が1792767600なら、差は86,400秒なので有効期間はちょうど1日です。このように差を86,400で割れば日数、3,600で割れば時間数がすぐにわかります。

ログを調べるときは、まず桁数で秒かミリ秒かを判断し、次に表示したいタイムゾーンを決めて変換するのが基本の流れです。Unix時間を日付時刻に直すには「UNIX時間から日付に変換」ツール、日付時刻からUnix時間を求めるには「日付からUNIX時間に変換」ツールが使えます。前者は秒とミリ秒の切り替えと、日本時間・UTCの表示に対応しています。後者は日付と時刻（秒まで指定可能）と日本時間・UTCのどちらで入力したかを選ぶと、Unix秒、ミリ秒、ISO 8601形式の文字列を同時に確認できます。

• 1日 ＝ 86,400秒、1時間 ＝ 3,600秒、1週間 ＝ 604,800秒
• 日本時間とUTCの差 ＝ 9時間 ＝ 32,400秒
• ISO 8601形式の例：2026-10-22T15:00:00.000Z（末尾のZはUTCを表す）

2038年問題とは何か

Unix時間に関連してよく話題になるのが2038年問題です。古いシステムの多くは、Unix時間を符号付き32ビット整数で保存していました。この型で表せる最大値は2,147,483,647で、これはUTCの2038年1月19日3時14分7秒、日本時間では同日12時14分7秒にあたります。

その1秒後になると値が桁あふれを起こし、最小値の−2,147,483,648に戻ってしまう可能性があります。この値は1901年12月13日20時45分52秒（UTC）を意味するため、日付が一気に過去へ飛び、期限判定や並べ替えが誤動作するおそれがあります。

現在の主要なOSや言語では64ビット整数で時刻を扱うのが一般的で、64ビットなら約2,920億年先まで表せるため実用上の上限はありません。ただし、古い組み込み機器、ファイル形式、データベースの列の型など、32ビットのまま残っている部分は今もあり得ます。長期の満期日や将来の予定日を保存するシステムでは、2038年より先の日付が正しく扱えるかを確認しておくと安心です。