exB - extreme B-AREA -

無敵の中年男性!的確な中年男性!難攻不落の中年男性!

サーバ管理 - 時刻と時間

時間と時刻は違うのだよ。

初稿:2002年 最終更新:2017-11-20

時刻と時間───

時計は時刻調整、電車は時間調整。高度情報化は時間の限界精度への挑戦でもある。

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

自転周期ベースの正確な1日の時間は 23 時間 56 分 4 秒、公転周期は 365日と 5時間 48分 46秒で、これが累積することで閏年が発生するのだが、その話は余談のところで。

地球の自転速度が未来永劫変化無しなら上記の方法でも別に構わないのかもしれないが、潮汐運動により自転の速度はわずか・・・平均して 100年に 2ms ( 1ms は 1/1000 秒)ずつ遅くなっている。つまり南中時刻を観測する方法では、自転の遅れにより正確に 1 秒といった単位時間を求めることが困難って話。そこで 1956年に地球の公転周期を元に、春分の日の南中から翌年の春分の日の南中まで(これを回帰年と呼ぶ)の 1/31 556 925.974 7 を 1 秒とすることになった。

しかし統計値を取るのに数年、いや数十年がかりになってしまいちょっと実用的でないし、公転周期だっていずれは~億年単位ではあるが~変化する。そのため 1967年に外因の影響を受けない正確な単位…いわゆるSI 単位系における絶対時間の基準として、セシウム原子が 9192631770 回振動する時間(周波数)を 1 秒と定義し、現在に至る(正確な定義は「セシウム 133 の原子の基底状態の 2 つの超微細構造準位の間の遷移に対応する放射の周期の 9 192 631 770 倍の継続時間」だとさ)。このような原子時計によって表される時間標準を周波数標準と呼ぶ。このように時刻には「生活時間」と「周波数標準」の 2 つの側面を持つに至っている。

なおSI 単位系において単位記号や単位の名称に省略形を用いることは許されない。秒の表記は“s”であって“sec”にしてはいけない(“/秒”は構わないけど“/sec”は NG )。

7 つある SI 単位長さのうち、本項で触れている時間の秒をはじめとして、長さのメートル、電流のアンペア、温度のケルビン、光度のカンデラ、物質量のモルは何らかの外因に影響を受けない普遍的な値が定義されているが、質量のキログラムだけはフランスの国際度量衡局に保管されている国際キログラム原器の質量となっている。理由はいろいろあるのだろうが、端的に言ってしまえば 1kg なりの重さを厳密に普遍的に定義することが難しいのだろう。なお重さだけ“キロ”グラムとなっているのは、原器が軽すぎると誤差を減らすのがこれまた困難なためと思われる。1円玉にほこりひとつついただけで、それをもとに 1t を正確に測ろうとすると無視できないズレになってしまう、ということ。

周波数標準を取得できる機器が周波数標準器で、一次標準器と二次標準器が存在する。

一次標準機
セシウムの周波数を基準にしたもの。周波数が安定しているため補正が不要。
二次標準器
ルビジウムや水晶の周波数を基準にしたもの。周波数がずれてしまうため補正が必要。

二次標準器は自作できるとかいう記事も見かける。いかん余計なことを考えるな。

様々な時刻の標準

以下、時刻の標準として利用される様々な基準。

JST ( Japan Standard Time、日本標準時)・・・時刻標準
日本の生活時間の基準。時報はこれに基づいている。明石市の東経 135 度線が基準位置。
UTC ( Coordinated Universal Time、協定世界時)・・・時刻標準
世界の生活時間の基準。各ロケーションの標準時(ロケーションは国とか地域ね)は UTC との差分になるので、日本の JST の場合 UTC に 9 時間を加えたものになる(+0900 (JST)と表記する)。
GMT ( Greenwich Mean Time、グリニッジ標準時)・・・時刻標準
かつての世界標準時で天体観測結果より決定される。現在は TAI を元にした UTC が採用されている。
TAI ( International Atomic Time 、国際原子時)・・・周波数標準
世界標準時の基準となる、原子時計により求められる時間。TAI に閏秒を補正することで UTC、つまり時刻の基準としている。
EAL ( Free Atomic Time、自由原子時)・・・周波数標準
世界中の原子時計の平均による時間。これに一次標準器と呼ばれる補正をかけることで TAI となる。

同期の基準は

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

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

なお電波を送信する GPS 衛星には原子時計が搭載され、ナノ秒単位の精度で時間を刻んでいるが、地上から約 2万キロの高度を 4キロ/秒で移動ともなると相対性理論(時間の進み具合は重力と移動速度に反比例する)によるズレが発生するため、この差分~ 1日あたり 38.1 マイクロ秒≒距離にして約10キロ ~もあらかじめ演算に盛り込まれている。

コンピュータの時刻調整

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

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

閏秒は TAI と UTC のズレが 0.8 秒を超える場合に実施される調整で、グリニッジ標準時の 0 時に行う。日本の場合 8 時 59 分 60 秒を挿入する。

ちなみに TAI による周波数標準が確立され UTC の運用が始まった 1972年から 2015年現在までの累積差分は 26 秒( 26 回実施している)。

結局 1 秒以下の正確さを求めるのであれば、JST/UTC による時刻同期と TAI による周波数標準との同期、両方を行う必要がある、ということだ。先に時刻標準を取得する方法に NTP があることを紹介したが、NTP サーバそのものがズレていた場合にはどうしようもない(複数の stratum 1 を利用できればベストだが数が少ないので負荷が集中し、レスポンスが悪化するため利用には制限がかけられています福岡大学など著名な stratum 1 サーバにアクセスが集中し運用に支障をきたす場合もある)。

実は NTP サーバ以外にも時刻や周波数標準を取得する方法は存在する。以下、JANOGのレポートから。

  • GPS 衛星( 1.2/1.5GHz, 30 秒周期)
  • JJY (標準電波* 40KHz, 旧 JG2AS)
  • テレビの色同期信号 (3.579545MHz)
  • NHK の時報 (時刻標準のみ)
  • ISDN の網同期信号 (NTT で実験中)
  • FM 文字放送時刻情報 (±18ms)

*JJY は、無線局のコールサインであり、通信総合研究所の登録商標( 10-107 454 )。

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

それぞれ扱っているのが時刻標準だけだったり周波数標準だけだったりという違いがあるが、標準電波は両方に対応し、かつほぼ日本全国をカバーしているためこれを受信するのが最も有効なのではないかと思われる。もちろん、受信器が必要。

問題は、通常のサーバ運用などでどのくらいの精度が求められるかであるが・・・標準電波受信や二次標準器をご家庭レベルで利用するというのはちょっと想像がつかない。一般的にはメールの送受信におけるタイムスタンプの正確さやログの整合性、信頼性の確保が最もポイントになると考えると、1日の最大のズレが JST/UTC から 1 秒以内に収めたいもの。同期のサイクルにも依存するが、NTP を利用すればまあ 1、2 秒以内で済むのではないか。最悪でもメールの送信時間のほうが受信時間より前だったなんてことになるまい。

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

初稿当時からけっこう情勢が変化した。2015年現在 GPS ロガーによるパソコンの内部時計の較正はすっかり確立され、GPS 時計もいっときに比べてだいぶお求めやすくなっているように(といっても十万円はくだらないが)、GPS が完全に民間レベルに浸透したおかげで個人レベルでの厳密な時刻同期も GPS を利用するのが容易になった。もっとも、電波時計の精度も従来の時計に比べれば桁違いに優れているわけで、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 はあくまでも時刻同期のための仕組みのためこのような解決方法を取れるが、UNIX の符号つき 32 ビット整数型の time_t に起因する 2038年問題などは時刻のユニーク性=タイムスタンプを永続的に保つ必要があるので無理。データが固定フィールドに格納されている場合など、符号なし 32bit 整数型(unsigned long int 型)とすることで 68年延命することは可能だが、同様の 32bit 空間のラップアラウンドは他のファイルシステムや C 言語プログラムなど広範囲に用いられているため 2000年問題よりはるかに深刻である。なお 2000年問題は yy-mm--dd を yyyy-mm-dd に変更することで問題を 8000年先送りしたに過ぎない。現在の C/C++では time_t を符号つき 64 ビット整数型のlong long int 型とすることで処理可能な範囲を 9 223 372 036 854 775 807 まで広げているが、これも 3000 億年先送りにしただけといえる(ミリ秒、ナノ秒レベルのタイムスタンプを用いると上位に使える桁が減るので油断はできない)。

余談

暦と閏年

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

365.2422日 ≒ 365 + 1/4 - 1/100 + 1/400 = 365.2425日

  • 4年に 1 回閏年を設けるが 100年に 1 回閏年を省き、なおかつ 400年に 1 回設ける
  • 西暦が 4 で割り切れる時には閏年< 100 で割り切れる時は閏年としない< 400 で割り切れる時は閏年とする

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

ちなみに地球の公転軌道は離心率 0.01 程度のほぼ円軌道から離心率 0.05 程度の楕円軌道にまで、約 41万年の大周期と約 10万年の小周期で変動している。また太陽の質量減少によって 1000年で 15m ほど外側に移動している。それでも公転周期への影響は無視できるレベル。

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

タイムコード

放送業界では様々な映像ソースを正確に同期させる必要があるため、コマごとに記録時間が埋め込まれている。これがタイムコード。編集時(オフライン)は閉じた系なので同期基準に絶対時間を用いてもよいが、放送時は協定時に合わせる必要がある。

参考資料

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