なぜ時刻の起点は1970年1月1日か(と2038年問題)

スマホもサーバーも時刻を「1970年からの秒数」で数える理由が腑に落ち、2038年問題やうるう秒の落とし穴まで、日付処理の設計勘所をまとめて持ち帰れる。

応用Unixエポック2038年問題うるう秒時刻OS最終更新: 2026-07-29
3つの要点
TL;DR
  1. Unix時間の起点1970-01-01 UTCは、初期Unixの開発時期に近く切りが良かったため慣習的に採用された。深遠な理由はなく、当初は60Hz刻みだった内部表現を秒に改めた際に固定された。
  2. 時刻を符号付き32bit整数の秒数で持つと、2038年1月19日03:14:07 UTCで正の上限を超え、負に折り返して1901年へ飛ぶ。これが2038年問題で、time_tの64bit化が本質的な解決策となる。
  3. Unix時間はうるう秒を無視して1日を常に86400秒として扱う。これが計算を単純にし相互運用を容易にした反面、真のUTCとの間にずれを生み、うるう秒挿入時の実装差という別の困難を招いた。

結論 — なぜ1970年1月1日なのか

横にスクロール

初期Unixが60Hz時刻から1970年起点の秒数へ移り32ビット上限が2038年問題になる図
Unix時刻の起点を歴史的な実装判断として捉え、表現幅が残した制約を示します。

コンピュータの多くは時刻を「1970年1月1日00:00:00 UTC からの経過秒数」という1つの整数で表します。これを Unix時間(Unixエポック時刻)と呼びます。なぜ1970年なのか——答えは拍子抜けするほど単純で、Unixが作られたその時期に近く、キリの良い年始だったからです。宇宙的・天文学的な必然はありません。初期Unixの開発が1969〜1971年に進んでいたため、直近の切りの良い基準点として1970年の元日が選ばれ、そのまま慣習として固定されました。

Unix時間の定義(要点)

Unix時間とは、協定世界時(UTC)1970-01-01 00:00:00 を 0 とし、そこからの経過秒数を数えた値です。過去は負の数で表されます。タイムゾーンやサマータイムに依存しない単一の絶対軸なので、機器や地域をまたいだ時刻の比較・保存に向きます。

当時の状況 — 60Hzで時を刻んでいた初期Unix

エポックが1970年に落ち着くまでには、実は短い試行錯誤があります。ごく初期のUnix(1971年ごろの文書)では、時刻を秒ではなく電源周波数由来の1/60秒(60Hzのティック)刻みで数えていました。基準点も当初は1971-01-01とされていた記録があります。しかし60分の1秒刻みだと、当時の32bit整数では数えられる範囲が2年半ほどしかなく、基準点を頻繁に動かさねばならない不便がありました。

ここで設計者が直面したのは、次のトレードオフです。

刻みの選び方分解能32bitで表せる期間問題点
1/60秒(初期案)高い(約16ミリ秒)約2.5年すぐ上限に達し基準点を動かし続ける必要がある
1秒(採用)秒単位で十分約136年実用上ほぼ困る場面がなく、扱いも単純

分解能を秒に落とせば、同じ32bitでも桁違いに長い期間を1つの基準点でカバーできます。日常の記録・比較には秒で十分——この割り切りが刻みを秒へ、基準点を動かさず済む1970年へと導きました。

決定打・経緯 — 秒への転換と32bit符号付き整数

決め手は「刻みを秒に固定し、起点も動かさない」という単純化でした。1970年代半ばには、時刻を1970-01-01 UTC 起点の秒数として扱う形が定着します。これを保持する型が、C言語やUnixで言う time_t です。歴史的な多くの実装で、time_t符号付き32bit整数(signed int)でした。

符号付き32bitが表せる最大値は 2^31 - 1 = 2147483647 です。これを起点からの秒数と解釈すると、限界に達する瞬間が決まります。

起点:   1970-01-01 00:00:00 UTC  =            0
上限:   2038-01-19 03:14:07 UTC  =   2147483647   ← 正の最大値
+1秒後: 折り返して負の最小値へ    =  -2147483648  ← 1901-12-13 20:45:52 UTC 相当

つまり2038年1月19日03:14:08 UTC の瞬間、カウンタは正の上限を1つ超え、2の補数表現の整数オーバーフローで一気に負へ折り返します。時刻は1901年へワープしたように見え、日付計算・有効期限・ソートなどが破綻します。これが2038年問題(Y2038、エポカリプスとも)の正体です。原因はバグではなく、表現幅(32bit)と刻み(秒)の組み合わせが尽きるという設計上の必然です。

なぜ符号付きだったのか

負のUnix時間(1970年より前の日付)を表現するため、time_t は符号付きが選ばれました。もし符号なし32bitなら上限は約2106年まで延びますが、1970年以前を表せなくなります。「過去も扱える対称性」を取った結果、正側の上限が2038年になったわけです。

なぜ、うるう秒を無視する設計になったのか。ここも意図的な単純化です。Unix時間は1日を常に厳密に86400秒として数え、実際のUTCに時々挿入されるうるう秒を勘定に入れません。おかげで「Unix時間 → 年月日時分秒」の変換が固定の割り算だけで済み、実装も相互運用も容易になりました。代償として、Unix時間は真のUTC経過秒と厳密には一致せず、うるう秒の瞬間に同じ値が2秒続く/時刻をわずかに引き延ばすなど、処理を各システムに委ねる曖昧さを残しました。

今への影響と教訓

64bit化が本質的な解決策です。time_t符号付き64bitにすれば表せる範囲は約2920億年に達し、2038年の壁は事実上消えます。現代の64bit Linux・macOS・多くのランタイムは既に64bit time_t を採用し、32bit環境向けにも移行が進みました。とはいえ、ファイル形式・通信プロトコル・データベース・古い組み込み機器には32bitの時刻が今も潜んでおり、Y2038は「片付いた過去」ではなく「順次片付けるべき現在進行形」の課題です。

表現幅符号実質の上限位置づけ
32bit符号付き2038-01-19歴史的な標準。2038年問題の当事者
32bit符号なし約2106年1970年以前を捨てる代わりに延命した亜種
64bit符号付き約2920億年現代の標準。実務上の恒久解決
設計の一般原則 — 基準点と表現幅はセットで決める

時刻に限らず、連番ID・カウンタ・オフセットなど「基準点からの数」を設計するときは、(1) 起点をどこに置くか、(2) どれだけの幅(ビット数)で数えるか、(3) 符号を持つか、の3点が寿命と可搬性を決めます。刻みを細かくすれば分解能は上がるが寿命は縮む——このトレードオフを最初に見積もることが肝心です。

うるう秒の教訓も鋭いものです。「単純さのために現実の一部を切り捨てる」判断は、日々の計算を軽くする一方で、切り捨てた現実が牙をむく瞬間(うるう秒挿入時のシステム間の挙動差)を生みます。近年はうるう秒を時間をかけて薄く均す「うるう秒スミア(leap smear)」で衝撃を和らげる運用が広がり、国際的にも2035年までにうるう秒の運用そのものを見直す方針が示されました。単純化は無料ではなく、切り捨てたぶんの帳尻を後で誰かが払う——時刻設計はその教科書です。

時刻を刻むカーネルの仕組みや time_t の実体はOS、整数オーバーフローとデータ型の設計はプログラミング、機器間で時刻を合わせるNTPなどの同期はネットワークを参照してください。

試験・面接での頻出ポイント
  • Unixエポック=1970-01-01 00:00:00 UTC。採用理由は「初期Unixの開発時期に近くキリが良かった」慣習であり、天文学的必然ではない
  • 2038年問題は 2038-01-19 03:14:07 UTC(=符号付き32bit秒の最大値2147483647)の直後にオーバーフローし1901年へ折り返す現象。解決は time_t の64bit化
  • 符号付きにしたのは1970年以前(負の時刻)を表すため。符号なしなら約2106年まで延びる
  • Unix時間は1日を常に86400秒とし、うるう秒を無視する。変換は単純になるが真のUTCとずれる

一段で言うと

1970年という起点に深い意味はなく、Unixが生まれた時期の切りの良い年始が慣習になっただけです。本当の設計判断は「刻みを秒にする」「32bit符号付きで持つ」「うるう秒は無視する」の3つで、それぞれが単純さと引き換えに寿命の上限(2038年)と現実とのずれ(うるう秒)を抱え込みました。基準点・表現幅・切り捨てる現実——この3点を最初にどう決めるかが、数十年後の帳尻を決めるのだと教えてくれます。

なぜ?の記事ガイド

なぜ時刻の起点は1970年1月1日か(と2038年問題)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

Unix

比較で見る軸

難易度: advanced / カテゴリ: なぜ? / タグ数: 6

導入後に効く点

時刻を符号付き32bit整数の秒数で持つと、2038年1月19日03:14:07 UTCで正の上限を超え、負に折り返して1901年へ飛ぶ。これが2038年問題で、time_tの64bit化が本質的な解決策となる。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
advanced
カテゴリ
なぜ?
タグ数
6

判断チェックリスト

  • 自社の用途が「Unix / エポック」に近いか確認する。
  • 強みである「Unix時間の起点1970-01-01 UTCは、初期Unixの開発時期に近く切りが良かったため慣習的に採用された。深遠な理由はなく、当初は60Hz刻みだった内部表現を秒に改めた際に固定された。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

Unixエポック2038年問題うるう秒時刻