Unix時間の変換

桁から単位を判断します。10桁は秒、13桁はミリ秒。どう読んだかも表示します。

桁を取り違えると53年ずれます

Unix時間でいちばん多い間違いは、秒とミリ秒の取り違えです。 同じ数字でも、どちらとして読むかで結果がまったく変わります。

1700000000 という10桁の数を秒として読むと2023年11月14日ですが、 ミリ秒として読むと1970年1月20日になります。53年のずれです。 逆に13桁の 1700000000000 を秒として読むと、 西暦5万年より先という現実には無い日付になります。

この計算機は桁数から単位を推定し、どう読んだかを画面に書きます。 推定が違っていれば、単位のボタンで直せます。 黙って秒として読んで1970年と表示するだけでは、間違いに気づけません。

なぜ1970年が基準なのか

Unix時間は1970年1月1日0時0分0秒（UTC）からの経過秒数です。 この基準の時刻をエポックと呼びます。

1970年が選ばれた理由は、Unixというオペレーティングシステムが作られた時期に近く、 切りのよい年だったからだと言われています。 深い意味のある年ではなく、どこかに基準を置く必要があったので置いた、という性質のものです。

基準がUTCで統一されていることには意味があります。 世界のどこで記録しても同じ数字になるので、 時差の違う場所の出来事を並べて比べられます。 時差を考えるのは、人が読む形に直すときだけで済みます。

2038年に起きること

Unix時間を32ビットの符号つき整数で持っているシステムには、期限があります。 32ビットで表せる最大の値は 2147483647 で、 これが2038年1月19日3時14分7秒（UTC）にあたります。

この時刻を1秒でも過ぎると、値があふれてマイナスに転じ、 1901年12月13日として扱われてしまいます。 2000年問題と似た構造ですが、こちらは桁数ではなく整数の上限が原因です。

いまの多くのシステムは64ビットで持っているので、この問題は起きません。 64ビットなら約3000億年先まで表せます。 古い機器や、32ビットのまま動き続けている組み込み機器では、 まだ確認が必要な場合があります。

Unix時間では、どの日も必ず 86400 秒です

Unix時間の決まりは、POSIX という OS の共通仕様に書かれています。そこには「経過秒数として表すとき、どの日も必ず 86400 秒として数える」とあります。 24時間 × 60分 × 60秒 = 86400 秒。この式に例外を作らないのが Unix時間です。

ところが、世界の時刻の基準である UTC（協定世界時）には、ときどきうるう秒が入ります。 原子時計が刻む1秒はとても正確ですが、 地球の自転は少しずつ揺らぎます。そのままだと時計と太陽の位置がずれていくので、 地球の自転から決めた時刻（UT1）との差が 0.9 秒以上にならないように、UTC に1秒を足したり引いたりする ── 情報通信研究機構（NICT）はそう説明しています。 1972年から2017年1月1日（日本時間の午前9時の直前）まで、 うるう秒は27回入り、すべて「足す」調整でした。 その結果、UTC は原子時計だけで刻む国際原子時（TAI）より37秒遅れています。

POSIX の解説（Rationale）には、Unix時間がうるう秒を無視するのは、 2つの時刻の差を引き算だけで出せるようにするためだ、と書かれています。 うるう秒で1秒長い日でも、Unix時間は 86400 秒として数えます。 だから仕様は Unix時間を「経過秒数に近い値」と呼び、 現実の時刻とどう合わせるかは実装ごとに決める、としています。 見た目は UTC でも UTC そのものとは限らない、とも書かれています。 国際地球回転・基準系事業（IERS）が2026年7月に出した告知（Bulletin C 72）は、2026年12月末にうるう秒を入れないことを伝えています。

2035年までに、うるう秒の決まりが変わります

1秒の長さは、1967年から原子で決まっています。NICT によると、その定義は「セシウム133原子の基底状態の2つの超微細準位間の遷移に対応する放射の 9 192 631 770 周期の継続時間」。地球の自転とは関係なく決まる1秒です。 一方で私たちの暮らしは太陽の動きと結びついているので、原子時計の時刻を地球の自転に合わせ続ける必要があり、 その合わせ方がうるう秒でした。

2022年、国際度量衡総会（CGPM）はこの決まりを見直す決議をしました。 うるう秒を入れると時刻に切れ目ができて、衛星測位や通信、送電といった大事なしくみが 正しく動かなくなるおそれがあること。入れ方が組織ごとにばらばらであること。 さらに最近の地球の自転の観測から、これまで一度も試されたことのない「引くうるう秒」が 必要になるかもしれないこと。こうした理由を挙げて、UT1 と UTC の差の上限を2035年までに広げると決めました。 新しい上限は、少なくとも100年は UTC が途切れずに続く値にするよう求めています。

うるう秒が入らない間は、UTC の1日も Unix時間の1日も同じ 86400 秒です。 つまりこの決議は、Unix時間と UTC のずれがこれ以上増えないようにする方向の決定でもあります。

日本の時刻が UTC より9時間進んでいる理由

地球は1日（24時間）で1回転、つまり360度まわります。360 ÷ 24 = 15 なので、経度が15度違うと時刻は1時間ずれます。 日本の標準時は東経135度の子午線（北極と南極を結ぶ線）の時刻と決められていて、 135 ÷ 15 = 9。これが「日本は UTC+9」の 9 です。

この135度を決めたのは、1886年（明治19年）の勅令第51号です。 同じ勅令の最初の項には、イギリスのグリニッジ天文台を通る子午線を、 経度を数え始める線（本初子午線）とすることも書かれています。 日本の時刻の基準は、グリニッジから東へ135度の線にあります。 NICT はいま、自分たちの原子時計で作った UTC（NICT）を「9時間（東経135度分の時差）進めた時刻」を 日本標準時として配っている、と説明しています。

日時の書き方の国際規格 ── 上の「ISO 8601」の行

上の表にある 2026-09-15T00:00:00.000Z のような書き方は、ISO 8601 という国際規格をもとに、インターネットの標準文書 RFC 3339 が定めた形です。年・月・日・時・分・秒の順に、大きい単位から小さい単位へ並べ、 日付と時刻の間に T、UTC なら最後に Z を付けます。 時差があるときは Z の代わりに +09:00 のように書きます。

RFC 3339 は、この形にした理由も書いています。 10/11/1996 のような書き方は国によって10月11日とも11月10日とも読めるので、 世界でやりとりするには向かない。 大きい単位から並べて桁数をそろえておけば、 文字列としてそのまま並べ替えるだけで時刻順になる。 曜日のように日付から計算できるものは、食い違いのもとになるので入れない。

うるう秒の扱いもこの文書に載っています。秒の欄はふだん 00 から 59 までですが、うるう秒が入る月末だけ 60 が許されていて、 例として 1990-12-31T23:59:60Z が挙げられています。「23時59分60秒」という、 うるう秒の日にだけ現れる時刻です。 この1秒を Unix時間でどう扱うかは、 上で見たとおり仕様が実装に任せています。

出どころ: The Open Group Base Specifications（POSIX）第4.19節「Seconds Since the Epoch」（新しいタブで開きます）とその Rationale（2018年版）（新しいタブで開きます）、NICT「国際原子時・協定世界時とうるう秒」（新しいタブで開きます）、NICT「日本標準時をつくる」（新しいタブで開きます）、NICT「うるう秒実施日一覧」（新しいタブで開きます）、IERS Bulletin C 72（新しいタブで開きます）、第27回 CGPM（2022年）決議4（新しいタブで開きます）、明治十九年勅令第五十一号（本初子午線経度計算方及標準時ノ件）（新しいタブで開きます）、RFC 3339「Date and Time on the Internet: Timestamps」（新しいタブで開きます）（第5節）の原文。