Unix時間とは？エポックからの秒数をやさしく解説

Unix時間の概要

POSIXのエポックからの秒数では、日を86,400秒として扱います。そのため、うるう秒も含めて実際に経過した秒数をすべて足した値とは異なります。

主要なポイント

基準点（エポック）：1970-01-01 00:00:00 UTC を 0 とする
単位：秒が基本（ミリ秒・マイクロ秒・ナノ秒を使う実装もある）
同じ瞬間なら、東京でもニューヨークでもUnix時間は同じ。ローカル日時との変換にはタイムゾーンを使う。

エポックとUTC・タイムゾーン

1735689600秒は、UTCでは2025-01-01 00:00:00、JSTでは同日09:00:00です。入力されたローカル日時をUnix時間へ変換するときにも、タイムゾーンやオフセットが必要です。

よくある誤解

「JST版のUnix時間」を作るために数値へ9時間を足す必要はありません。足すと別の瞬間になります。
夏時間（DST）の有無は「表示側」のローカルタイムゾーン解釈で決まる

表現形式（秒・ミリ秒・ナノ秒）

単位と数値型はセットで確認します。Pythonのtime.time()は小数秒、JavaScriptのDate.now()はミリ秒です。桁が多いことと、時計の測定精度が高いことは別です。

代表的な単位

2025-01-01 00:00:00 UTC：秒なら1735689600、ミリ秒なら1735689600000。
マイクロ秒は秒の10^6倍、ナノ秒は10^9倍。現在付近のナノ秒をJavaScriptのNumberで整数として扱うと精度を失うため、BigIntや文字列などを検討します。

桁判定の目安

10桁と13桁は現在付近の目安にすぎません。古い日付・負の値・小数もあるため、桁数で自動判定せずAPIの単位を確認します。

各言語・シェルでの変換例

固定値1735689600を変換する例です。シェルはGNU dateとPOSIX系シェル、PythonはPython 3、JavaScriptはNode.jsやブラウザーのコンソール、PHPはPHP CLIなどで実行します。

GNU dateで変換する

macOS標準のdateとはオプションが異なります。UTCとJSTで同じ瞬間を表示します。

date -u -d @1735689600 +"%Y-%m-%dT%H:%M:%SZ"
TZ=Asia/Tokyo date -d @1735689600 +"%Y-%m-%dT%H:%M:%S%:z"

Pythonで変換する

from datetime import datetime, timezone
print(datetime.fromtimestamp(1735689600, tz=timezone.utc).isoformat())
# 2025-01-01T00:00:00+00:00

JavaScriptで変換する

const seconds = 1735689600;
console.log(new Date(seconds * 1000).toISOString());
// 2025-01-01T00:00:00.000Z

PHPで変換する

<?php
$dt = new DateTimeImmutable("@1735689600");
echo $dt->setTimezone(new DateTimeZone("Asia/Tokyo"))
    ->format("Y-m-d\\TH:i:sP"), PHP_EOL;
// 2025-01-01T09:00:00+09:00

SQLのタイムゾーンを確認する

MySQLのFROM_UNIXTIMEはセッションのタイムゾーンで表示します。PostgreSQLのto_timestampは時点を表すtimestamp with time zoneを返し、表示はセッションのTimeZoneに従います。UTCの表示になると思い込まず、接続ごとの設定を確認します。

注意点（2038年問題・うるう秒・時差）

実務では以下の落とし穴に注意すると安全です。

2038年問題（time_tが32ビットの場合）

符号付き32ビット整数の最大値2147483647は、2038-01-19 03:14:07 UTCです。この時刻までは表せますが、次の03:14:08 UTCは範囲外です。
CPUやOSが64ビットでも、DB列・通信形式・アプリが32ビット秒を使っていないか確認します。扱える範囲は時刻型ごとに異なります。

うるう秒

POSIX時間はうるう秒を数えません。うるう秒の前後の実時計の動作は、同期方式や実装によって異なります。
処理にかかった時間を測る用途では、時計の補正で戻る可能性がある現在時刻より、単調時計（Pythonのtime.monotonicなど）を使います。

タイムゾーンと表示

発生済みの時点はUTC基準で扱います。「毎朝9時」のような予定は、地域のタイムゾーンとローカル時刻も保存します。
APIやDB間で秒/ミリ秒の単位違いに要注意（桁数で誤変換しやすい）

実務ベストプラクティス

ロギング、API、DB保存、フロント表示の一貫性を保ち、単位ミスや時差起因の不具合を防ぎます。

推奨事項

発生済みイベントはUnix秒やオフセット付き日時など、時点が一意に分かる形で保存する。
I/F仕様書に「単位（秒/ミリ秒）」と「タイムゾーン」を明記
テストでは境界（うるう年、月末、00:00:00、桁違い）を含める
可観測性：ログにUTCとローカル（例：JST）の両方を出せる仕組みが便利

よくある質問

Q. Unix時間はJSTですか？

JSTの別数値はありません。同じUnix時間から、UTCやJSTの日時へ変換します。

Q. 10桁と13桁の違いは？

現在付近では秒とミリ秒の違いでよく見られますが、桁数だけでは確定できません。

Q. 2038年問題の影響は？

符号付き32ビット秒を使う箇所に影響します。64ビットOSという理由だけで安全とは判断できません。

主な用途

利用例

サーバーログや監視のタイムスタンプ
JWT等の発行時刻iat・有効期限exp（単位は仕様に従う）。値を読めることと署名検証済みであることは別。
DBのイベント時刻・ソート・範囲検索
フロントエンドでの相対時刻表示（「5分前」など）

Unix時間とは？