実際に返送される時刻情報は整数部32ビット、小数部32ビットの計64ビットで表現されています。
[ﾊﾟｹｯﾄ情報] (Request 210.173.160.57 -> 192.168.0.10)
[MAC層] (EtherII(DIX))
[IPﾍｯﾀﾞ]
[UDPﾍｯﾀﾞ]
送信元ﾎﾟｰﾄ番号 : 0x007B (123) ntp Network Time Protocol
送信先ﾎﾟｰﾄ番号 : 0x007B (123) ntp Network Time Protocol
ﾃﾞｰﾀ長 : 0x0038 (56 ｵｸﾃｯﾄ)
ﾁｪｯｸｻﾑ : 0xDA1C
[NTPﾊﾟｹｯﾄ]
ﾌﾗｸﾞ : 0x1A
閏秒指示子 : 0 (警告無し)
ﾊﾞｰｼﾞｮﾝ : 3 (IPv4のみ)
ﾓｰﾄﾞ : 2 (対象受動 passive)
階級 : 2 (従属的な基準)
ﾎﾟｰﾘﾝｸﾞ間隔 : 10
精度 : 0xEE (0.000004 sec)
ルート遅延 : 0x19000000 (0.000381 sec)
ルート分散 : 0x75030000 (0.013504 sec)
基準ID : 0x38A0ADD2 (210.173.160.56)
基準ﾀｲﾑｽﾀﾝﾌﾟ : 2006-12-28 07:57:34.2200 UTC
基点ﾀｲﾑｽﾀﾝﾌﾟ : 1970-01-01 00:00:00.0000 UTC
受信ﾀｲﾑｽﾀﾝﾌﾟ : 2006-12-28 08:01:16.8137 UTC
送信ﾀｲﾑｽﾀﾝﾌﾟ : 2006-12-28 08:01:16.8138 UTC
小数部32ビットということはナノ秒以下の分解能があるわけで本当かいな？
そのほかに上位の時間標準との遅れなどの情報も含んでおり、さらに厳密に言えば
クライアント～サーバ間の応答時間を測定してそれらも加味して時刻を決定する必要があるのですが
そういうのはバッサリ切って送信時刻情報の整数部だけを取り出しました。
たとえば上のようなレスポンス内で送信タイムスタンプの32ビット整数部は「C93DF84C」
で、3376281676秒となります。
これは協定世界時1900年1月1日午前0時からの経過時間を示しているので
9時間を足して通常の日付時刻表示に変換すれば日本時間表示ができます。
変換するためのにはCの標準関数でlocaltime()というのがあるのですが、
ところがこれは1970年1月1日午前0時からの経過時間を引数にするので使えません。
これは手作りする必要がありそうです。時分秒だけであれば86400のモジュロをとれば算出できるので
これを液晶表示器に送ればＮＴＰ時計になりそうです。
ただし、常時NTPサーバにリクエストして時刻を取得するのはサーバに負担がかかるのでいけません。
実際にはリアルタイムクロックか、ソフト／ハードのタイマで計時しておいて１時間に１回とか
正時に補正を掛けるのが正しいようです。
ところでNTPの実験をしていて自分のパソコンが標準時より10分も進んでいるのに
初めて気づきました．．．．．
