時刻を合わせる前に、何に合わせるのかを知っておく必要があります。世界の「正しい時刻」は誰が決めていて、コンピューターはそれをどう数えているのでしょうか。

第1回では、時刻がずれると何が起きるかを見ました。第2回では、UTC・うるう秒・エポック・タイムゾーンといった時刻の基礎と、コンピューターの時計の仕組みを扱います。

天文の時刻と原子の時刻

時刻には、地球の自転をもとにした「天文の時刻」と、原子の振動をもとにした「原子の時刻」の2系統があります。

• 昔の1秒は、平均した1日の86,400分の1だった。英国グリニッジ天文台の子午線での平均太陽時がGMT（グリニッジ平均時）で、これを天文観測で精密にしたものが世界時（UT）
• 観測地点ごとに求めた値がUT0、地球の自転軸のふらつき（極運動）を補正して地球全体で共通にしたものがUT1（季節変動も補正したUT2は、今はほぼ使わない）
• ところが地球の自転は、潮汐による減速や大気・海洋・地球内部の動きで揺らぐ
• そこで1967年に、1秒はセシウム原子の振動 9,192,631,770 回分と定義し直された。この秒で数え続けた時刻が国際原子時（TAI）で、世界の約450台の原子時計から国際度量衡局（BIPM）が計算する

天文の時刻は観測して決め、原子の時刻は数えて決めるのです。

UTC・TAI・UT1・GMT・JSTの関係

• UTCは、TAIと同じ原子の秒で刻み、うるう秒でUT1に寄せた時刻。NTPが配るのはUTC
• UTCそのものはBIPMが毎月、各国のデータから後で計算して公表する時刻で、各国の機関が実時間で作る近似値をUTC(k)と呼ぶ。日本ではNICT（情報通信研究機構）のUTC(NICT)で、JSTはこれに9時間を足した時刻

ポイント
サーバーの内部とログはUTCで持ち、人が見るときにタイムゾーンで変換するのが基本。

うるう秒

UTCはTAIと同じ原子の秒で刻むため、そのままでは地球の自転（UT1）から少しずつ離れます。そこで1972年から、UT1との差が0.9秒を超えないよう、国際地球回転・基準系事業（IERS）の判断で、UTCに1秒を足し引きしてきました。これがうるう秒です。

• 挿入は原則6月末か12月末で、23時59分59秒の次に23時59分60秒を入れる（日本時間では8時59分60秒）
• 27回すべてが1秒を足す調整で、最後は2016年12月31日（日本時間2017年1月1日）
• NTPは、パケットのLI（うるう秒指示子）で事前に予告する（第3回）

しかし「1分は60秒」「時刻は戻らない」を前提にしたプログラムは多く、2012年にはLinuxカーネルの不具合で多数のサーバーのCPU使用率が急上昇し、2017年には時間差が負になってCloudflareのDNSの一部が失敗しました。うるう秒は、障害の種でもあったのです。

うるう秒の廃止の決定

冒頭の「うるう秒の日は準備が必要か」への答えは、「もう入らない見込み」です。

• 2022年11月の第27回国際度量衡総会（CGPM）は決議4で、UT1とUTCの差の上限を遅くとも2035年までに大きくすることを決め、少なくとも100年はUTCを連続させられる新しい上限を次の総会に示すよう求めた
• これを受けて2026年10月15日、第28回CGPMは決議5（決議案Cとして提出）を採択し、「連続したUTCを2027年5月20日から有効にし、|UT1−UTC|の上限を3,600秒（1時間）とする」ことを決めた。うるう秒の廃止は、2035年から2027年5月20日に前倒しされた
• 前倒しの背景は、地球の自転が速まり、前例のない「1秒を削る」負のうるう秒が必要になりそうなこと。2025年の専門家の会合は、その確率を2035年までに30%と見積もり、重要インフラを混乱させる危険が高いとされた
• なお、IERSは2026年12月末もうるう秒を入れないと発表しており、TAI−UTCは37秒のまま

最後のうるう秒は2016年末で、制度として止める段階に入りました。ただし、うるう秒を前提にした仕組み（第7回で扱うリープスメアなど）は、当面は残ります。

エポック：UNIX時刻とNTP時刻

コンピューターは、時刻を「ある起点（エポック）からの経過秒」で数えます。起点は仕組みごとに違います。

$ date +%s
1790407000
$ date -u -d @0
Thu Jan  1 00:00:00 UTC 1970
PS> [DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
1790407000
PS> [DateTimeOffset]::FromUnixTimeSeconds(0).UtcDateTime
1970年1月1日 0:00:00

• NTP時刻とUNIX時刻の差は2,208,988,800秒（70年分、うるう日17回を含む）
• どちらもうるう秒を数えないため、うるう秒の瞬間は同じ秒を2回数えるか、実装が前後で調整する
• PowerShellではDateTimeOffsetを使うと、UTCで確実に扱える

2036年問題

NTPのタイムスタンプは、1900年1月1日からの秒を32ビットの符号なし整数で表します。表せるのは約136年分で、2036年2月7日6時28分16秒（UTC、日本時間15時28分16秒）に秒の欄が桁あふれして0に戻ります。

• RFC 5905は、この区切りをエラ（era）と呼び、1900年からをエラ0、桁あふれ後をエラ1とする
• パケットにはエラの番号が入らないため、受け取った側は自分の時計から今のエラを判断する。クライアントの時計がサーバーと68年以内に合っていれば、エラをまたいでも正しく計算できる
• chronyもビルド日の前50年〜後86年に割り当てるため、現行版は2036年以降も動く
• 危ないのは、秒の値を常に1900年からとみなす古い実装や組み込み機器と、RTCの電池切れなどで大昔に戻った機器

同じ秒の値でも、自分の時計しだいで136年違う日付になるのです。

2038年問題

$ date -u -d @2147483647
Tue Jan 19 03:14:07 UTC 2038
PS> [DateTimeOffset]::FromUnixTimeSeconds([int]::MaxValue).UtcDateTime
2038年1月19日 3:14:07

2036年問題はNTPの時刻の形式、2038年問題はOSやアプリが内部で使うUNIX時刻の形式の問題で、別物です。有効期限が2038年を超える証明書、長期のタイマー、未来の日付の計算では、2038年より前に表面化することがあります。

タイムゾーンとRTC：LinuxとWindows

$ timedatectl
               Local time: Sat 2026-09-26 16:16:19 JST
           Universal time: Sat 2026-09-26 07:16:19 UTC
                 RTC time: Sat 2026-09-26 07:16:19
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
PS> Get-TimeZone | Select-Object Id, BaseUtcOffset
Id                  BaseUtcOffset
--                  -------------
Tokyo Standard Time      09:00:00

• 1台でWindowsとLinuxを切り替えて起動すると、Linuxが RTCに書いたUTCを、WindowsがJSTとして読むため、時計が9時間ずれる。日本は夏時間がないため、Linux側をset-local-rtc 1にすると実害が少なく済む
• サーバーでは、全台のタイムゾーンをそろえることが重要。冒頭の「JSTとUTCが混在して9時間ずれて見える」は、ログを並べる前にどちらかへそろえて比べる

コンピューターの時計（RTCとシステムクロック）

コンピューターには2つの時計があります。

• RTC（リアルタイムクロック）：マザーボード上の電池で動く時計（BIOSクロック、ハードウェアクロックとも呼ぶ）。電源を切っても動くが、精度は高くない
• システムクロック：CPUのタイムスタンプカウンター（TSC）などの進みを時間に換算して、OSが刻む時計。アプリケーションやログはこちらを使う
• 起動時にOSがRTCを読んで初期値にし、以後はシステムクロックが独立して進む。NTPが合わせるのもシステムクロックで、RTCへは定期的に書き戻す（Linuxではchronyのrtcsyncでカーネルが11分ごとに書き込む。第4回）
• RTCの電池が切れると、起動直後の時刻が大きく狂う。仮想マシンのRTCは仮想のもので、起動時の時刻はホストから受け取る（第4回・第6回）

時刻の源

社内の時刻も、たどれば原子時計に行き着きます。

• 日本標準時は、NICT（東京都小金井市）が複数のセシウム原子時計と水素メーザーで作るUTC(NICT)に9時間を足したもの
• 1PPSは、GNSS受信機や原子時計などの機器が出力する1秒ごとのパルスで、衛星が直接出す信号ではない
• アナログ電話回線のテレホンJJYは2024年3月末で終了し、光電話回線の光テレホンJJYが続いている

考えてみよう

1. 担当サーバーのログは、UTCとJSTのどちらで記録されていますか。混在していたら、障害調査で時刻をそろえるときに何に気をつけますか。
2. 職場に、2036年や2038年の桁あふれの影響を受けうるものはありますか（更新できない組み込み機器、32ビットのOS、MySQLのTIMESTAMP型など）。
3. うるう秒の調整をやめると、UTCと太陽の動き（UT1）の差はどうなりますか。システムの運用で何が楽になり、何が残りますか。

ヒント：この記事の関係表、うるう秒の廃止の年表、2036年問題・2038年問題の表と日付が手がかりです。timedatectl・Get-TimeZoneで、実際の設定を確かめてみてください。

まとめ

• 時刻には天文の時刻（UT1）と原子の時刻（TAI）がある。NTPが配るのは、TAIの秒でUT1に寄せたUTC
• TAI−UTCは37秒。JSTはUTC(NICT)＋9時間
• うるう秒は27回で、最後は2016年末。2026年10月の第28回CGPMで、廃止は2027年5月20日に前倒しされた
• NTP時刻は1900年、UNIX時刻は1970年が起点。2036年問題（NTP）と2038年問題（UNIX時刻）は別物
• OSの中はUTC。RTCの扱いはLinux（UTC）とWindows（ローカル時刻）で違う
• NTPが合わせるのはシステムクロック。社内の時刻も、たどれば原子時計に行き着く

次回は、NTPがネットワーク越しにどうやって時刻のずれを測り、どう直すのかを扱います。

連載「NTP入門」全11回

1. なぜ時刻同期が必要か
2. 時刻の基礎知識（この記事）
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期
6. ネットワーク機器・仮想基盤
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習