CreaTools LogoCreaTools
Tech Notes
UnixTime Converter

UnixTimeとは何か｜エポックからの秒数で時刻を表す仕組み

2026-02-13

一言で言うと

UnixTime（エポック秒、UNIXタイムスタンプ）は 「1970年1月1日 00:00:00 UTC からの経過秒数」 です。

それだけ。たったこれだけの定義で、世界中のサーバが同じ時刻を共有しています。

なぜそんな表現が必要なのか

計算が簡単

2024-01-01 00:00:00 UTC → 1704067200
2024-01-02 00:00:00 UTC → 1704153600
                          ───────────
差分:                       86400 (=24時間×3600秒)

「2024-01-01 と 2024-01-02 の差は何時間？」を計算するのに、月の長さや閏年を考えなくていい。引き算するだけで秒数が出ます。

タイムゾーンに依存しない

UnixTimeはUTC基準の絶対時刻。日本のサーバが返した 1704067200 を、米国のサーバが受け取っても同じ瞬間を指します。「東京の23時はNYで何時？」のような変換を、保存形式自体は気にしなくていい。

比較が文字列ソートで効く

数値なので <、> で大小比較が即座にできます。"2024-01-01" のような文字列では時差を考えると面倒。

「秒」だけじゃない

単位桁数（現在）用途
秒10桁UNIX系コマンド、PHP time()、DB（一部）
ミリ秒13桁JavaScript Date.now()、Java
マイクロ秒16桁高精度ログ
ナノ秒19桁科学計算、Go time.UnixNano()

UnixTime Converter では秒・ミリ秒に対応しています。

どこで使われているか

データベース

CREATE TABLE events (
  id BIGINT,
  created_at BIGINT  -- UnixTime（ミリ秒）
);

DBによっては TIMESTAMP 型ではなく BIGINT でUnixTimeを保存することがあります。タイムゾーン問題を回避できる、文字列より小さい、というメリット。

API

{
  "user_id": 123,
  "last_login": 1704067200
}

REST API、特に多言語クライアントを想定するAPIではUnixTimeが多用されます。日付文字列だとフォーマット混乱（ISO 8601 vs RFC 2822 vs ...）が起きるため。

ログ

[1699876543] INFO: user logged in

タイムスタンプが数値だと、grep / sort / awk で扱いやすい。ログ集約システム（fluentd, Vector等）も内部ではUnixTimeで処理することが多い。

知っておくべき制限

2038年問題（Y2038）

32bit符号付き整数（int32）でUnixTimeを表すと、2038年1月19日 03:14:07 UTC で桁あふれ（overflow）します:

2147483647 = 2038-01-19 03:14:07 UTC
2147483648 → -2147483648（負数になり1901年に戻る）

現代のシステムは64bit化が進んでいるため、新規開発で起きることはまずありません。古いC言語の組み込み機器・古いMySQLの INT カラムなどに残っている可能性があるので、要注意。

閏秒（leap second）

UnixTimeは「閏秒を含まない」前提で計算されます。実際の地球の自転とのズレ（数秒）が累積していくため、ミリ秒精度の物理現象を扱う場合は別途補正が必要。一般的なWebアプリでは無視してOK。

1970年以前

理論的には負のUnixTimeで1970年以前を表せますが、多くのライブラリ・APIは負数を想定していません。歴史的な日付を扱うなら別の表現を検討してください。

なぜ「1970-01-01」なのか

UNIX OSが開発された時期に近く、設計者たちにとって都合の良い基準点だったから、というだけです。技術的な必然性はなく、慣習として固定されています。

そのため:

  • Windows（FILETIME）: 1601-01-01 から100ナノ秒単位
  • .NET（DateTime.Ticks）: 0001-01-01 から100ナノ秒単位
  • Excel: 1900-01-01（または1904-01-01）から日数

各プラットフォームで基準点が違います。Excel⇄UnixTime変換などは別途オフセット計算が必要。

UnixTimeを扱うときのコツ

状況推奨
新規DB設計TIMESTAMP WITH TIME ZONE か BIGINT ms 単位
API設計ISO 8601文字列 or UnixTime（ミリ秒推奨）。混在しない
ログ出力UnixTime + 人間可読な日付（両方）
クライアント表示UnixTimeから現地TZに変換して表示
期間計算UnixTime同士で引き算

関連記事

UnixTimeは「人間の都合を無視して、機械が扱いやすい時刻表現」。だからこそ世界共通言語として機能しています。