exB - extreme B-AREA -

サーバ管理 - 時刻と時間

時間と時刻は似て非なるのだよ。

初稿：2002年 最終更新：2021-09-01

時刻と時間───

時計は時刻調整、電車は時間調整。自動巻き時計は人類の叡智の結晶であり、高度情報化は時間の限界精度への挑戦でもある。

時間を考える場合、ライフサイクルの基準にしている時刻＝（ civil time、「今何時？」ってやつで、ある特定の一瞬）と、定量的な時間（ duration、曲の再生時間とか、まとまった繋がり）の違いを考慮する必要がある。時刻はもともと地球の自転を元にした時間の概念で生活時間といってもよい。専門用語では常用時、市民時と呼ばれている。生活時間の基本は太陽が観測点に対し真南にくる、いわゆる南中のサイクルで、これを 1日としてカウントしている。1938年の段階では季節による南中時刻のバラツキを平均化し、1日の 1/86400 を 1 秒という天文秒を基準単位としていた（太陽時間）。

天文座標や世界時（ Universal Time ）の決定を行っている IERS が定めた地球の自転周期は 23時間 56分 4.098 903 691秒 。地球が太陽を一周する公転周期＝太陽年は 365日と 5時間 48分 45.4441秒で、この差分が累積することで閏年が発生するのだが、その話は余談のところで。また太陽が天球の赤道を一周する恒星年 は 365日と 6時間 9分 9.765 秒 で、太陽年とのズレ（歳差）は春分点や秋分点の移動という形で現れる。

地球の自転速度が未来永劫変化無しなら上記の方法でも別に構わないのかもしれないが、潮汐運動などの影響によりミリ秒単位で変動している。つまり南中時刻を観測する方法では、自転の不安定さにより正確に 1 秒といった単位時間を決めることはできない。そこで 1900年時点の地球の公転速度を元に春分の日の南中から翌年の春分の日の南中まで（これを回帰年と呼ぶ）の 1/31 556 925.974 7 を 1秒とすることが 1956年に決まった。これは 1750年から1892年までのおよそ 140年間の観測記録がもとになっており、事実上 1820年の 1日の長さ（ LOD , Length of Day ）～の 1/86400 を 1秒の基準としたことになる。

しかし地球の公転周期だって変化する～長くなりそうなイメージだが、実際には短くなっているし、やもすると統計値を取るのに百年レベルの年月を要してしまう。さらに計測時期によって精度が変わる恐れもある（当然後の時代のほうが精度は増すだろうが、基準となる 1900年の回帰年を再計測するのは不可能）。そのため 1967年に外因の影響を受けない正確な物差し…いわゆるSI 単位系における絶対的な時間の基準として、絶対零度においてセシウム原子が一番低いエネルギー状態から 2段階分変化するときに放射する電磁波の振動を 9,192,631,770回繰り返したときの時間の長さを 1 秒とした。実際にセシウム原子から得られる時刻は周波数標準となりようやく時間の厳密な物差しが定まった（かのように思えた。

なお電磁波の振動…つまりは放射周期の値を 9,192,631,770 としたのは 1900年（実質は 1820年）の回帰年ベースの秒に準じたためで、1967年の回帰年ベースとでは無視できないレベルの違いが生じていた。のちのうるう秒の調整を考えると放射周期の値をもっと扱やすいものに変えるという手もあるにはあったが、すでに 1900年ベースの秒を基準とした物理定数による様々な論文や技術が蓄積されており、そちらへ配慮した結果らしい。まあ現代物理学の根幹ともいえるアインシュタインの一般相対性理論（ 1915年）、シュレーディンガー方程式（ 1926年）、ゲージ理論（ 1940年代）あたりが根こそぎ影響受けるんだから、しゃーないわな。

原子時計と一次周波数標準器

セシウム原子の共鳴周波数を取得する機器の原子時計は世界に 400台ほど運用され、これらの加重平均をとった時系が自由原子時となる。自由原子時は 10^-16 というきわめて高安定な時系を得られるが確度が測定条件に左右されるため、要因を特定しズレを較正する一次周波数標準機が用いられている。こちらは世界に 20台ほどしかない。SI 秒の定義は海抜 0m / 真空中 / 絶対零度 / 電磁場なし / 静止状態という理想環境下で、他の原子や地場、重力が少しでも存在すると不確かさの原因となる周波数シフトが発生する。最新のレーザー冷却原子泉標準器（ 1.4×10^-15）であっても理想環境の実現は無理なので、原子時計は数を集めて安定性を確保し少数精鋭の一次標準機で確度を得る、という感じ。

クォーツ時計に用いられる水晶の精度は 10^-6～10^-7 で、月に数秒程度の誤差が生じる。1日にすると100ミリ秒程度なので、NTP なりで定期的に同期すれば生活レベルで困ることはまずない。

様々な時刻の標準

時刻として利用される主な標準をまとめるとこんな感じ。

EAL （ Free Atomic Time、自由原子時）・・・周波数標準

世界中の周波数標準器の加重平均による時刻。これに一次標準器で較正をかけることで TAI を得る。

TAI （ International Atomic Time 、国際原子時）・・・周波数標準

自由原子時に較正をかけて得られた時刻。TAI にうるう秒を補正することで UTC、つまり時刻の基準としている。

UTC （ Coordinated Universal Time、協定世界時）・・・時刻標準

世界の生活時間の基準。TAI と UT1 の差を整数秒に調整したもの、ともいえる（裏を返せば最大で 0.95秒のズレ～ DUT, deltaUT1 ～を許容する必要がある）。

各ロケーションの標準時（ロケーションは国とか地域ね）は UTC との差分になるので、日本の JST の場合 UTC に 9 時間を加えたものになる（+0900 (JST)と表記する）。

JST （ Japan Standard Time、日本標準時）・・・時刻標準

日本の生活時間の基準。時報はこれに基づいている。明石市の東経 135 度線が基準位置。

UT0 / UT1 / UT2

天文台による観測から得られた世界時。UT0 は観測地点の時刻、UT1 は UT0 から極運動と経度による地域差を補正した時刻、 UT2 は UT1 の周期的なズレを平均化した時刻。UT1 は UTC よりも厳密な世界時が求められるケースで用いられる

日常生活では UTC で何ら問題はないが、地球の時点や公転の変動は不規則で、太陽年とのズレは天測しないと得られない。また前述の UTC のうるう秒補正は整数秒単位で行われるため、リアルタイムな世界時を反映しているのは UT1 になる（多くの場合そこまでは求められないが）。

GMT （ Greenwich Mean Time、グリニッジ標準時）・・・時刻標準

かつての世界標準時で、グリニッジ子午線（経度 0度）における平均太陽時。UTF ±0000 となるイギリスにおいては UTF と同義で用いられる。

ちなみにロレックスの GMT は Grand Master Time の略。

UTF が UT1 ではなく TAI を基準としているのは、1秒の長さを揃えるため。

同期の基準は

身の回りに電波時計がけっこう増えた。俺の G ショックもそうだし。まあ人間が時間を知るレベルの精度においては、電波時計で十分事足りる。開門ダッシュのタイミングもどうやら電波時計の時間に合わせているようだ（なぜか 1 秒遅れるが）。

ちなみに我々が日常目にするものの中でもっとも高いレベルの時刻の精度が求められるのは、今や携帯電話にも搭載されている GPS 受信機である。GPS は三点測量の要領で（実際にはもっと複雑であるが、イメージとしてはそんなもの）自分の位置を測定するが、衛星との距離の測定に用いる L1 電波は波長が異なるだけで速度は光と同じ秒速約30万km であるから、わずか 1µs （ 1 マイクロ秒＝ 0.001 ミリ秒＝ 1/1 000 000 秒）の違いですら 300m ものズレとなってしまう。測距に最低必要な衛星の数は 3 つだが、GPS 端末程度の大きさに一次標準機なみの精度の自律時計を実装するのは現実的でないため、4 つめの衛星を加えることで時間誤差を補正している。

参考：固有時と座標時

一般相対性理論により、時間の進み方は重力の影響を受けることがわかった（たとえば富士山の頂上では 7万年に 1秒時間が遅れる）。この重力の影響を受け実際に刻まれた時間が固有時で、特定の位置を基準とした時間を座表時と区別している（座標軸を固定した固有時が座標時、ともいえる）。つまり異なる場所で完全に同一の時間を刻むのはもとより不可能という話なのだが、なんのことはない、一般相対性理論とニュートン力学の差がマクロな世界では無視できる範囲に収まるのと同じこと。

ただGPS 衛星に搭載される原子時計は数百ピコ秒レベルの精度で TAI を刻んでいるが、地上から約 2万キロの高度を毎秒 4キロもの速度で移動ともなると地表付近との固有時の違いが無視できない大きさとなるため、差分～ 1日あたり 38.1 マイクロ秒≒距離にして約10キロ ～もあらかじめ演算に盛り込まれている。

座標時はどこを基準座標とするかによって体系が変わってくる。太陽系重心を原点とした太陽系準拠系（ BCRS ）における固有時を太陽系座標時（ TCB ）、地球重心を原点とした地球準拠系（ GCRS ）の固有時を地心座標時（ TOG ）としている。いずれも実測は不可能だが、ジオイドにおいては理屈上 TAI と同じ速さとなる。これを地球時（ TT ）とし、TTから重力の影響を引くことで TCG が求められる。こんなもの天文学くらいしか利用されることはないので忘れていい。覚えておくべきはこの世において時間さえも絶対的なものではないってこと。

コンピュータの時刻調整

2021年8月大幅に加筆

では、コンピュータの時間同期を行う場合、何を基準とすべきなのか？恐らくそのコンピュータやシステムを運用する規模や目的に応じて変わるものとなってくるはずだが、大雑把にいえば JST / UTC と TAI のどちらに合わせるかという選択になる。

NTP と PTP

TAI や UTC という時間の基準が決まったはよいが、パソコンのリアルタイムクロックの精度は実に怪しいものでクオーツ時計以下だったりする（月差 数十秒くらいは普通に出る）。 そこでオンラインのコンピュータ機器を UTC に同期する手段として RFC 958、NTP が 1985年に標準化された。まだインターネットがインターネットとして知られるようになる前のことである。インターネット（の前進である ARPANET ）はネットワークの冗長化に重きを置き QoS の補償はなかったため、単純にサーバが配信する時刻を信頼しても遅延によるズレが発生してしまう。そこで送信時刻と受信時刻、ジッターの情報を通信内容に含めることで推測や補正を容易にした。またサーバ側は階層構造を取り、複数の上位サーバを参照することで加重平均を取れるようになっている。分解能はミリ秒。クライアント専門の SNTP も RFC 1769 として同時に標準化されたが、2010年の RFC 5905 で NTP と統合された。

リアルタイムクロックはミリ秒単位で刻まれるが、8086 ですら 5 MHz ＝ 200ナノ秒周期なわけで、こんな精度では 5GHz に達した現代の CPU に割り込み制御といった緻密な動作を行うには役不足のため、OS は電源投入時にリアルタイムクロックから時間情報を得た後より高精度なイベントタイマーによる起動時からの積算時間を CPU 制御などに用いている（リアルタイムクロックとの同期はシャットダウン時に行うのが一般的）。

同期方法は2種類。

STEP モード

サーバーから取得した時刻を即時反映する。一見すると問題ないように思えるが、時刻のズレ具合によっては時間が過去に戻る可能性があり、データベースジャーナルのタイムスタンプやシリアル実行型のシステムでは致命的な不具合に繋がる恐れがあるほか、うるう秒を挿入する必要がある。

SLEW モード

サーバーから取得した時刻になるよう、時間をかけてゆっくり調整する。ただし 600 秒を超えるズレは一気に反映する。基本的に時間を進める方向で、1秒間に 最大5ミリ秒の補正を行う（遅れている場合はその逆）ためシリアル型システムに向く。うるう秒の挿入も不要。

どちらを選ぶかは利用環境に依存する。時刻戻りが許されなかったりうるう秒のサポートが不安な場合は SLEW モード、そうでなければ STEP モードでよい。なおいくらリアルタイムクロックの確度が低いといってもさすがに 600秒＝10分のズレというのはそれなりの長期間電源を落としてない限りなかなか発生しないので、運用開始後に SLEW モードの逆戻りを心配する必要はない（というかその心配をするような状況ではそれ以上の不具合が生じてるはず。

NTP には DHCP のようなサーバ配信によるアドレス告知の仕組みがなく、参照先はデフォルトのまま用いるか、自分で調べて設定するしかない。そのため time.windows.com など OS デフォルトの参照先にアクセスが集中しレスポンスが悪化するケースが多々あった。また今でこそ time.nict.jp を筆頭に多くの優れた NTP サーバを利用できるようになったが、ブロードバンドが普及し始めた 20世紀末はなかなか悲惨なことになっていて、福岡大学やウィスコンシン大学など、数少ない民間の public stratum 1 サーバが運営側の知らぬままルータのファームウェアにハードコードされ、負荷が集中して自ネットワークの運用に支障をきたすトラブルもあった（福岡大学は長いこと苦労していたが、ついに NTP の公開を取りやめた）。NTP 個々のトラフィックは微々たるものだが IoT の普及によりノードはますます増えるわけで、懸念は解消されていない。

NTP が策定された 1980年代当時はミリ秒レベルの精度 / 分解能で問題になることはほぼなかったのだが、21世紀になりあらゆる産業が IT 化されると、スマートフォンを筆頭に地上デジタル放送、スマートグリッド、スマートシティなどその系においてマイクロ秒レベルの精度を要求されるケースが一気に増加した。

GPS が提供する時刻は十分な精度があるものの、衛星を目視できない環境では基本的に利用できない。

こうした要求に応えるべく、産業用の時刻同期システムとして PTP , Precision Time Protocol が IEEE1588-2002 として規格化された（現在の主流は IEEE1588-2008, PTP v2 で、2002との互換性はない）。プロトコルレイヤは NTP と同じアプリケーション層で 、ハードウエアタイムスタンプやバウンダリークロック、トランスペアレントクロックといった精度補償のための取り決めが実装されている。

NTP が WAN 越しの運用を前提に世界統一の時刻系（ UTC ）を提供するのに対し、PTP の本質はその系におけるローカル周波数標準として TAI の積算時刻を提供することにある。また Windows の時刻分解能は未だにミリ秒レベルのため NTP で十分用が足りるため、通常の LAN に PTP を導入するメリットはほぼないといってよい。人間の耳の分解能は 3ms が限界とされるので、趣味の DTP の範囲ではこれまた問題になることはないだろう（ Windows の場合、カーネルミキサーの悪さのほうがよっぽど深刻である）。

自身が何らかの基準となるようなものの場合、TAI と同期を取りつつ時刻用の補正値を加味するのが理想である。補正そのものが正確に行われなければ意味がない。では UTC/JST への同期はどうか？NTP そのものの精度を無視できたとしても、今度はうるう秒の調整が一定のタイミングでしか行われないことによるズレが生じる恐れがある。生活時間的にはまず問題なかろうが、通信業界では数 ms レベルでの正確さが求められることがあるため、運用目的によっては不十分。

結局 1 秒以下の正確さをとことん求めるのであれば、JST/UTC による時刻同期と TAI による周波数標準との同期、両方を行う必要がある、ということになる。

その他の時刻同期

実は NTP サーバ以外にも時刻や周波数標準を取得する方法はけっこう存在した。

• GNSS 衛星位置情報システム（世代にもよるがおおむね同期精度±10ナノ秒程度）
• JJY の標準電波 （旧 JG2AS 、電波時計が拾ってるやつ、東日本：おおたかどや山標準電波送信所、西日本：はがね山標準電波送信所、遅延±4ミリ秒程度)
• アナログ放送時代のNHK 時計 (遅延±500マイクロ秒程度、2011年停波)
• NTTの ISDN の網同期信号 (同期精度±100ナノ秒程度、2024年終了予定)
• FM 文字放送時刻情報 (遅延±30ミリ秒程度、2014年修了)

時刻のズレには 2種類あって、同期精度（発信側のゆらぎ）はジッター、遅延（発信側との距離や経路）はレイテンシ。本家 GPS 衛星の軌道は高度約 2万キロ、JAXA の準天頂衛星みちびきは 3～4万キロと静止軌道よりも遠く、電波≒光の速さをもってしても送信から受信まで 100ミリ秒程度の時間を要するため受信側はこの遅延も考慮して補正を行っている。また複数衛星を同期（特に 4つ目）することで精度を高めている。対して標準電波の受信は基本的に 1 対 1 のため、オートでレイテンシを補正するのはけっこう難しい。

放送や通信のデジタル化は高品質と高付加価値、高効率をもたらしたが、時刻同期という点においてデジタルは経路の複雑化や符号化と復号による処理ロスの影響でレイテンシやジッターが生じやすくく、アナログのほうが勝っていたように思う。

一般相対性理論によると重力は時間の進行を遅らせる効果があり、地表と衛星上では 1 秒の長さが異なってくる。正確な同期を行うため、GPS の場合は衛星側の時計を毎秒 445×10^-12 ずつ遅くなるよう補正を行っている。

それぞれ扱っているのが時刻標準だけだったり周波数標準だけだったりという違いがあるが、標準電波は両方に対応し、かつほぼ日本全国をカバーしていること、レイテンシは地域差があるが原理的にジッターが発生しないことからこれを受信するのが最も有効なのではないかと思われる。もちろん、受信器が必要。

多くのケースではメールの送受信におけるタイムスタンプの正確さやログの整合性、信頼性の確保が最もポイントになると考えると 1日のズレ幅はせいぜい 500 ミリ秒以内に収めたいもの。1日 1回の同期で十分達成可能であるが、家庭利用ならともかく職場の LAN 内のノードすべてが同時アクセスするとレイテンシやジッタを誘発≒かえって精度が落ちかねないので注意。

結論：通常の利用であれば NTP で十分。但し同期タイミングには注意すべし。

初稿当時からけっこう情勢が変化。GPS が完全に民間レベルに浸透したおかげで個人レベルでの厳密な時刻同期も容易になった。えらい世の中になったもんだ。

NTP の 2036年問題

NTP では 1900年1月1日 0時0分0秒（ UTC ）を起点とした経過秒数を 32 ビットで返している。裏を返せばカウントできるのは 0xFFFFFFFF 秒＝ 4 294 967 295 秒で、2036年2月7日 6 時 28 分 15 秒（ UTC ）に 0 リセットされてしまう。これが NTP の 2036年問題と呼ばれるものである。この問題を回避するため、SNTPv4 を定義したRFC 4330で最上位ビットが 0 の場合 2036～2104年、最上位ビットが 1 の場合は 1968年から 2036年と 68年ごとにスイッチする方法（つまり符号付き 32 ビット化みたいなもの）が提示された。

このような過去を無視した解決方法を取れるのは NTP/SNTP があくまでも時刻同期のための仕組みだからであって、符号つき 32 ビット整数型の time_t に起因する C 言語などの UNIX の 2038年問題の場合は時刻のユニーク性＝タイムスタンプを保持する必要が高いため難しい。データが固定フィールドに格納されている場合など、符号なし 32bit 整数型（unsigned long int 型）とすることで 68年延命することは可能だが、同様の 32bit 空間のラップアラウンドは他のファイルシステムや C 言語プログラムなど広範囲に用いられているため 2000年問題よりはるかに深刻である。なお 2000年問題は yymmdd を yyyymmdd に変更することで問題を 8000年先送りしたに過ぎない。現在の C/C++では time_t を符号つき 64 ビット整数型のlong long int 型とすることで処理可能な範囲を 9 223 372 036 854 775 807 まで広げているが、これも 3000 億年先送りにしただけといえる。余裕に映るかもしれないがマイクロ秒 / ナノ秒レベルのタイムスタンプを用いると上位に使える桁を消費するので下手すると 30万年まで減る（次の氷河期入ってるだろ）。

タイムコード

放送業界では様々な映像ソースを正確に同期させる必要があるため、一定のタイミングで時間情報が埋め込まれている。これがタイムコードで日本はアメリカに倣い SMTPE タイムコードが用いられてきたが、デジタル放送で STD-B4 や STD-B68 に置き換わった。閉じた系（オフライン）の編集時は独自の同期基準を用いてもよいが、搬送の際は協定時に合わせる必要がある（ PTP でだいたい解決できるはず）。

SMTPE タイムコードを MIDI 機器と同期するためのフォーマットとして MIDIタイムコードがある。

余談

ピンポイントな時刻の話が続いたが、もう少し長期的な時間の流れまで話を広げてみる。

暦と閏年

生活時間の延長というか象徴が暦だろう。暦は地球が太陽のまわりを 1 周する（公転）のを基本単位、1年としている。閏年を補正するのは自転や公転周期の変動による差分よりも、自転周期が 24 時間を欠くことによる差分が原因。そのため公転周期の近似値（有理数近似というらしい）は 365.2422日となり、現在の暦の標準であるグレゴリオ暦では、

としている（これでも 0.003日のズレがは生じる）。記憶に新しいミレニアムイヤーの 2000年はすべての条件で割り切れるため閏年である。閏年補正をきちんとしているプログラムはよいが、そうでない場合・・・いわゆる西暦 2000年問題の餌食になってしまったのかもしれない。

ちなみに地球の公転軌道は離心率 0.01 程度のほぼ円軌道から離心率 0.05 程度の楕円軌道にまで、約 41万年の大周期と約 10万年の小周期で変動している。また太陽の質量減少によって 1000年で 15m ほど外側に移動しているが、公転周期への影響は無視できるレベルらしい。ぶっちゃけ公転軌道の変化は周期云々よりも太陽との距離の変化や地軸の歳差運動など、いわゆるミランコビッチ・サイクルによって生じた地球気候に大きく影響するらしい（自転周期も大陸氷河の位置によってかなり変わってくる）。

自転周期は地核の運動や潮汐摩擦、巨大地震等によって変化しており、19 世紀末から 2 ミリ秒程度の遅れがある。またうるう秒の挿入をパターン化できないのは自転周期の変化が一定方向ではないためで、2015年現在は 20 世紀末と比べてむしろ速くなっている（マクロでは長期化するが、季節ごとでも増減が起きている）。

暦も太陽暦と太陰暦と太陽太陰暦といった種類があるが、キリがないし主題と離れていくので本稿では取り上げない。

先述の NTP は UTP 準拠であるためタイムスタンプレベルでうるう秒の挿入をサポートしている、TAI 準拠である PTP のタイムスタンプはNTP の SLEW モードのようにあくまでも積算された SI 秒の連なりで、うるう秒が挿入されない（プロトコルとしては定義している）。

参考資料

EE/CIS の ntpd 配布ページ

http://www.eecis.udel.edu/~ntp/

IPA ISEC の ntpd のインストールと設定

ここだけでたいていの NTP 話は済んでしまうと思います。

http://www.ipa.go.jp/security/awareness/administrator/secure-web/chap4/4_ntpd.html

インターネットマルチフィード株式会社（ MFEED ）の Experimental NTP Servers

Public Stratum 2 として NTP サーバを公開しています。

http://www.jst.mfeed.ad.jp/index.html

情報通信研究機構（ NICT ）の日本標準時プロジェクト 公開 NTP

Public Stratum 1 として NTP サーバを公開しています。

http://www2.nict.go.jp/aeri/sts/tsp/PubNtp/

Kenji Ito 氏の FreeBSD 4.4 + date,ntpdate,ntpd

http://www.hayagui.com/ntp.html

松阪大学 奥村晴彦教授による NTP のページ

http://www.matsusaka-u.ac.jp/~okumura/networking/ntp.html

九州工業大学 材料物性学研究室の ntpdate コマンドマニュアル和訳

http://opt-1.matsc.kyutech.ac.jp/ntpdate.html

Masaaki Sato 氏のサイトの ntp のクライアントモード利用

http://masaaki.sato.nakano.tokyo.jp/gps/ntp-linux/ntp-client.html

UNO Shintaro 氏のサイト（桜時計作者）

http://www.venus.dti.ne.jp/~uno/

IETF （英語）

NTPv3 は RFC1305 で定義されています。

http://www.ietf.org/rfc/rfc1305.txt

SNTP は RFC1361 及び 1769 で定義されています。

http://www.ietf.org/rfc/rfc1361.txt

http://www.ietf.org/rfc/rfc1769.txt

SNTPv4 は RFC2030 で定義されています。

http://www.ietf.org/rfc/rfc2030.txt

SNTPv4 for IPv4, IPv6 は RFC4330 で定義されています。

http://www.ietf.org/rfc/rfc4330.txt

NTPv4 は RFC5905 で定義されています。

http://www.ietf.org/rfc/rfc5905.txt

独立行政法人　通信総合研究所の日本標準時表示ページ

http://www2.crl.go.jp/cgi-bin/JST.cgi

国立研究開発法人産業技術総合研究所 計量標準総合センター (NMIJ)

国際単位系（ SI ）日本語版

通産省：工業技術院計量研究所の時間標準のページ

http://www.nrlm.go.jp/standard/time.html

JANOG のネットワーク時刻同期ワーキンググループ（ ML ）

http://www.janog.gr.jp/wg/timesync-wg.html

中間報告

ML への参加はJANOGの趣旨をご理解の上、http://www.janog.gr.jp/wg/index.htmlよりどうぞ。

日本臨床工学技士会のコンピュータ西暦 2000年問題における閏年問題の可能性

http://www.iijnet.or.jp/JACET/y2k/y2k29.htm

横浜こども科学館のうるう秒のページ

http://www.city.yokohama.jp/yhspot/ysc/leapsec.html

宇宙航空研究開発機構（ JAXA ） 今いる場所・時間がわかる測位とは？

みんな大好き JAXA の GPS 解説。

http://www.jaxa.jp/countdown/f18/overview/gps_j.html

• 初稿：2002-12-31
• 改訂：2003-05-14
• 改訂：2007-10-11
• 改訂：2015-10-20