2026年12月末にうるう秒の追加なし
(datacenter.iers.org)- IERS Bulletin C 72により、2026年12月末のUTCにはうるう秒が追加されないため、時刻測定・配信システムは別途挿入処理を準備する必要はない
- UTCとTAIの差は、2017年1月1日0時UTCから追って通知があるまで
UTC-TAI = -37 sのまま維持される - うるう秒の導入有無は UT1-TAIの変化 に基づいて決定され、可能な時期は6月末または12月末
- Bulletin Cは6カ月ごとにUTCの時間ステップ（time step）を発表するか、次の可能日に時間ステップがないことを確認する
- 2026年末のUTC配信には新しい補正値は不要で、既存の
UTC-TAI = -37 sの関係を引き続き使用すればよい
IERS Bulletin C 72のUTC告知
- IERSが2026年7月6日にParisで発行したBulletin C 72は、2026年12月末にうるう秒を導入しないと明らかにした
- 告知の対象は、時刻の測定と配信を担う機関
- 重要な値は次の2つ
- 2017年1月1日0時UTCから追って通知があるまで
UTC-TAI = -37 s - 2026年12月末にはUTCに新たな時間ステップはない
- 2017年1月1日0時UTCから追って通知があるまで
うるう秒の決定と告知周期
- うるう秒は UT1-TAI の変化に応じてUTCに導入される場合がある
- 導入可能な時期は毎年 6月末 または 12月末
- Bulletin Cは6カ月ごとに送付される
- UTCに時間ステップが生じる場合はそれを発表する
- 次の可能日に時間ステップがない場合はそれを確認する
1件のコメント
Hacker News のコメント
この予測不可能性は何が原因で生じるのか気になる。地球の自転と公転は小数点以下かなりの桁まで分かっているものだと思っていたが、地質活動や天候のような要因が自転速度の違いを生み、予測を難しくしているのだろうか？
これらのモデルは記憶では低次の三角多項式なので、予測不可能性を完全にモデル化できたとしても、打ち切り誤差のために非常に高い精度で配布するのは難しく、衛星などにすでに組み込まれているため、任意に複雑にすることもできない
ちなみにうるう秒は近く廃止される予定で、2035年に段階的に停止されると認識している。ロシアが GLONASS 衛星を更新する時間が必要だったため遅れた、と記憶している
https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... がこれに最も関連するグラフで、垂直方向のジャンプはうるう秒を表している。IERS には自転の他の次元に関するグラフもあるが、このグラフが見やすい
「地球の自転速度は気候および地質学的事象に反応して変化するため、UTC のうるう秒は不規則に配置され、正確には予測できない」
https://en.wikipedia.org/wiki/Leap_second
だから、うるう秒を足したり引いたりしようとするのはあまり良い考えではないと思う。こうしたことを気にするのは実質的に宇宙機関だけで、彼らは必要な補正値を適用すればよく、全員に影響を与える必要はない
一般人にとってこの drift が及ぼす現実的な影響は GPS くらいだが、GPS はすでに独自の時計とのオフセットを送信しており、受信機が補正できる。GPS の時計は UTC とも TAI とも異なる
これはむしろアンチニュースではないか？ 現代のコンピューティングシステムにあまりに多くの問題を引き起こすため、別途告知があるまでうるう秒の導入を止めた、とぼんやり記憶している
今は37秒の差であり、クリスマスがイースターの頃までずれ込むのではないかと誰も心配する必要はない。この問題は、他の多くの問題よりもずっと責任ある形で将来世代に引き継いでよいと思う
6か月ごとに告知が出るのは、元の国際条約の文言に合わせるための手続きにすぎない
うるう秒がしばらくなかった理由は、TAI と UT1 の間の drift が遅くなり、実際には非常にゆっくり反対方向へ動いているからだ
時刻が±60秒ほどずれても誰も気づかないだろうから、10年に一度くらい任意のうるう秒を入れ、10年前に告知して全員がシステムを整理する時間を与える方が、管理しやすそうに見える。世界全体が調整して実行するのに6か月というのは、ばかげて楽観的だ
5歳児に説明するように言うと、これはUNIX タイムスタンプにどんな影響を与えるのか気になる。特に保守モードのものや、ほとんど管理されていないものについて
自分の仕事にはこの程度の精度は必要ないが、確実に必要な分野はあるはずだ
そのため、うるう秒が挿入されると UNIX タイムスタンプで参照できない物理的な1秒が生じることがあり、うるう秒が削除されると実際には存在しない秒に対する UNIX タイムスタンプが生じることがある
time()とclock_gettime(CLOCK_REALTIME)の結果はうるう秒の影響を受ける新しいうるう秒は NTP 経由でシステムに届く。残念ながら NTP は、うるう秒が導入されるという表示フラグだけを配布し、オフセット自体は配布しない。ただし配布される時刻そのものがすでにうるう秒の影響を受けているため、NTP クライアントが必ず知る必要はない
一方、GPS や PTP のような他の時刻同期方式は、うるう秒の影響を受けない時間尺度を使い、UTC オフセットを追加情報として配布する。受け取った時刻を最後に修正するのはクライアント側の役割だ。カーネルにはうるう秒用の
clock_adjtime()パラメータがあるNTP クライアントがある手動システムなら、稼働中に新しいうるう秒に合わせて時刻が変わる。Linux は UTC 時刻を優先して扱うため、これが RTC デバイスに保存され、再起動後も維持される
CLOCK_TAIは TAI 時刻を返すべきに見えるが、一般的な Linux デスクトップ・サーバー配布版ではオフセットすら設定されず、CLOCK_REALTIMEと同じ時刻を返すほど二級扱いだ/etcの中には、どこかのパッケージに含まれるうるう秒リストファイルがあり、このファイルを更新するにはシステム更新が必要だ。従来の NTP ソフトウェアがこのパッケージを動的に更新するとは思わない。ただし、このファイルを使うソフトウェアも多くない何らかの init サービススクリプトがこれをパースしてカーネルの UTC オフセットを設定するなら、更新前まではシステムの
CLOCK_TAIが世界の他より1秒遅れる可能性がある。しかし私の知る限り、Linux の UTC 時刻には何の影響も与えない「時間の測定と配布を担う機関へ」という文言は、史上最高レベルに仰々しい
肩書きまで SF っぽい
UTC-TAI オフセットが -37 秒のままなら、UTC-GPS オフセットも -18 秒のままという意味
TAI と GPS の間には一定の 19 秒オフセットがある
こういう状況で Spanner のようなシステムはどうなるのか気になる
厄介事なのか、それとも大したことではないのか？
厳密な順序保証が必要なシステムでは、各デバイスがグローバル時計との同期を保ち、時計周期の長さだけがごくわずかに変わるので機能する。実際、元の Spanner 論文に載っていたと記憶している
まれに、単調発振器の秒を使って地球自転の秒を無視するシステムもあるが、いつかそれを実時刻に変換しなければならないなら、時間が経つほど破局が蓄積していくため、一般には良い考えではないとされる
なので、包括的な時刻管理を備えた高信頼性システムは、こうした選択に大きく揺さぶられることはなさそう
Temporal API があれば、ブラウザや Node.js などはその時点付近の演算で時刻を正しく扱えるのだろうか？ それとも計算を壊さないために更新が必要なのだろうか？
そのため、データベースなしでも過去と未来の UTC カレンダー計算を簡単に行え、必ずしも小数秒を扱う必要もない。うるう秒は、OS が 1 秒を繰り返すか飛ばすか、あるいはうるう秒の前後の一定期間にわたって秒の長さを調整する形で処理する
ほとんどの日付・時刻 API は基本的に、ビジネス機能向けのカレンダーおよび壁時計演算を支えるよう設計されている。科学目的に必要な SI 秒が必要なら、ハードウェアレベルまで必要な意味論を提供し保証する別の API や機能を使うべき
同様に、スレッドの sleep のようなソフトウェア機能のためのタイマーが必要なら、単調時計のような専用インターフェースを使うべき。うるう秒が段階的に廃止されても、この状況は大きく変わらない。うるう秒調整があってもなくても、例えばミューテックスアルゴリズムが Unix タイムスタンプに依存するのは、昔も間違いだったし今後も間違い
ちょっと聞いてくれ。赤道にジェットエンジンを付けて 180 度回して、時間を得たり失ったりすればいい。そしてそれを自分のスヌーズボタンにつなげればいい
「UTC と TAI の差は 2017 年 1 月 1 日 0 時 UTC から別途通知があるまで UTC-TAI = -37s」とある
これは原子時計が日時計より 37 秒遅れているという意味なのか？ 2017 年に言及している理由も分からない
UTC の 1 日は正確に 86400 SI 秒と定義されている。しかし実際の平均太陽日は数ミリ秒長い。地球自転の不規則性のため差は一定ではないが、平均的な差は時間とともにゆっくり大きくなると予想されている。SI 秒は原子時計で数えるので、UTC は原子時計の 86400 秒ごとに日付を進める
一方、平均太陽が正午に到達するたびに日付を進める日時計は、UTC より数ミリ秒遅く日付を進める。実際の太陽は一年を通じて空を横切る速度が変わるため、平均太陽を使う必要がある
別の言い方をすると、日時計が正確に 86400 秒と呼ぶ各期間は、原子時計基準では数ミリ秒長い
こうしたことが毎日積み重なってほぼ 1 秒になると、UTC にうるう秒を挿入し、その日の長さを 86400 秒ではなく 86401 秒にする。UTC は単に原子時計の時間を数えるだけでなく、多くの人間活動が空の太陽の位置と結びついているため、太陽とも同期していなければならないから
人間は「太陽と同期」を「平均太陽と 1 秒以内」と定義した。つまり UTC の正午が、本初子午線における平均太陽の正午から 1 秒以内であってほしいということ
したがって 37 秒とは、うるう秒を使わなかった場合に、平均太陽の正午が UTC の正午からどれだけ遅れていたかを意味する。UTC の正午の時点で、平均太陽は空で本初子午線を通過するまでまだ 37 秒足りなかったはず