サーバー時刻同期ガイド

UTC、TAI、GPS 時間、および地方常用時間は異なる目的を果たします。 TAI (国際原子時) は、提供されるクロックから BIPM によって計算される連続的な原子時間スケールです。うるう秒は追加されません。 UTC (協定世界時) は TAI とは整数秒だけ異なり、常用時間帯の国際基準です。 GPS 時刻 は、1980 年の開始時に UTC と一致していましたが、うるう秒は追加されませんでした。

[米国によると、 Naval Observatory](2026 年 9 月時点の https://maia.usno.navy.mil/information/eo-values), TAI は 37 秒、GPS 時刻は UTC より 18 秒進んでいます。これらのオフセットは、将来のうるう秒ポリシーの下で変更される可能性があります。

SI 秒の BIPM 定義 は、セシウム 133 の摂動のない基底状態の超微細遷移周波数を 9,192,631,770 Hz に固定します。セシウム クロックは、この原子遷移を周波数基準として使用します。

主要な標準と新しい光時計では、測定された不確実性が異なります。 「N 年に 1 秒」という 1 つの数字ですべてのデバイスを説明することはできません。国立計量機関は基準を比較し、国際的な時間スケールに貢献しています。 NTP を介したこれらの標準の配布は、原子時計に直接接続されない Clock-Tani のブラウザ表示とは別のプロセスです。

ネットワーク タイム プロトコル (NTP) は、ネットワーク上でコンピューターの時計を同期します。 RFC 5905 (NTPv4) は、タイム サーバーの階層と、クライアントの送信時間と受信時間、およびサーバーの受信時間と送信時間の 4 つのタイムスタンプを使用したオフセット計算について説明しています。クライアントは、これらの観測値を使用してシステム クロックを制御できます。

パフォーマンスは、サーバーの基準、デバイスのクロック、ネットワーク遅延、および非対称性に依存します。 RFC の高速ローカル ネットワークの例は、公共のインターネットやすべてのオペレーティング システムに対して一定の精度を保証するものではありません。 NIST のインターネット タイム サービス は、ユーザーから見える精度はネットワークの安定性と相互関係に大きく依存すると述べています。

Clock-Tani は、ブラウザーで NTP を実行したり、デバイスのクロックを調整したりしません。そのサーバー時間ページは、Web API 応答とラウンドトリップ タイミングとの差を推定します。

コンピュータと携帯電話の時計は、ハードウェア オシレータとオペレーティング システムの計時機能に依存しています。発振器の周波数は温度、使用年数、デバイスの設計によって異なりますが、単一の周波数、毎日のドリフト レート、または同期間隔がすべてのコンピューターに適用されるわけではありません。

多くのオペレーティング システムは、有効化され接続されている場合、ネットワーク タイム サービスを使用してクロックを定期的に調整できます。方法とスケジュールは設定とデバイスによって異なります。オフセットが予期しないと思われる場合は、自動時刻とタイムゾーン設定を確認してください。ブラウザの比較は、ネットワークの影響を受ける推定値として扱います。 NIST の計時に関する FAQ は、クォーツ時計の誤差が発振器にどのように依存するかを示しています。

デフォルトの サーバー時間ページ は、Clock-Tani の API に対して 3 つのリクエストを行います。応答ごとに、ブラウザーで測定された往復時間の半分が API の Date.now() タイムスタンプに追加され、中間のレイテンシを持つサンプルが選択されます。これにより、1 つの遅い外れ値の影響が軽減されます。 NTP 同期や精度証明ではありません。ページに戻るかネットワークを再接続すると、別の測定がトリガーされる可能性があります。

サイト固有のビューの場合、最近の結果がまだキャッシュされていない場合、サーバーはターゲットに対して 1 つの HEAD リクエストを作成します。有効な推定オフセットは最大 60 秒間再利用できます。ターゲットの HTTP Date ヘッダーとラウンドトリップ時間を調べて、ブラウザーへの API ホップを個別に測定します。 HTTP-date の分解能は 1 秒です。ヘッダーが欠落しているか信頼できない場合は、インターフェイスが区別する別のソースまたはデバイスの時刻が発生する可能性があります。ハーフ RTT 補正は、同様の送信遅延と戻り遅延を想定しており、固定精度は保証できません。

現在の UTC ルールでは、UTC を地球の自転時間 (UT1) に近づけるために必要な場合にうるう秒が使用されます。 IERS Bulletin C は、うるう秒が導入されるかどうかを発表します。正のうるう秒では、UTC の 23:59:59 の後に 23:59:60 を挿入できます。これには、異常な分を処理するソフトウェアが必要です。

CGPM 決議 4 (2022) は、2035 年までに許容される UT1 と UTC の差を増やし、より継続的な UTC に向けた実装計画を準備することを求めています。すでに最終的な 2035 年以降の調整方法を指定したり、すべてのうるう秒の処理が特定の日に終了するという包括的な約束をしたりするものではありません。

金融市場、航空およびナビゲーション システム、通信ネットワーク、電力網はすべてタイミングを使用しますが、必要な精度と検証方法はアプリケーションによって異なります。たとえば、高頻度アルゴリズム取引活動に関する EU 委任規制 2025/1155 では、特定の活動に対して 100 マイクロ秒の最大 UTC 乖離を指定しています。これは、すべての取引や業界に共通の規則ではありません。

衛星ナビゲーション、基地局調整、およびグリッド測定には、独自のタイミング要件があります。 Clock-Tani などの Web 応答に基づくブラウザー ビューは、これらのシステムの検証済みクロックではありません。結果的な決定には、関連するシステムの公式タイムソースと記録を使用してください。

サーバー時間ページ を開いて、デバイスの時計を Web 応答ベースの Clock-Tani 推定値と比較します。デフォルトのビューはすでに 3 つの API サンプルを取得し、中遅延の結果を選択します。 3 回リフレッシュしても、これらのオフセットは認定された「実際の」デバイス エラーにはなりません。

このページには、測定された往復遅延値やオペレーティング システムの NTP 状態の診断ではなく、推定されたミリ秒のオフセットが表示されます。別の見積もりが必要な場合は、接続を変更した後に「再度同期」を使用してください。継続的な差異が予期しないと思われる場合は、デバイスの自動時刻とタイムゾーン設定を確認してください。このブラウザーの測定には普遍的な正常/注意/重大なしきい値はなく、時間に敏感なイベントの前に再起動することが一般的な前提条件ではありません。

Clock-Tani のサーバー時間ページには、デバイス時間の横に Web 応答ベースの参照が表示され、その差が推定されます。デフォルトのソースは、Clock-Tani 自身の API タイムスタンプです。サイト固有のビューでは、ターゲットの HTTP Date ヘッダーまたは明確に示されたフォールバックを使用できます。

この比較では、コンピュータの NTP サービスが動作しているかどうかを確認したり、絶対的なエラーを証明したり、チケット販売者の内部営業時間を確認したりすることはできません。ネットワーク遅延やサーバークロックエラーが影響する可能性があります。販売、試験、その他の重要な締め切りについては、主催者の公式発表と提出記録を信頼してください。このツールは基準を観察して再確認するのに役立ち、設定した時間までカウントダウンできます。