ハクソク

世界を動かす技術を、日本語で。

BIPMがUTCへのうるう秒の追加を停止することを決定

2026年10月16日原文(bipm.org)

概要

  • UTC（協定世界時） の継続性確保に向けた技術的対応を決定
  • 2027年5月20日 より連続的なUTC運用を開始
  • UT1-UTCの差は最大3600秒（1時間） に制限
  • 負のうるう秒導入リスクとインフラへの影響を重視
  • 国際機関との連携とユーザーへの周知を推進

CGPM第28回決議5号：UTCの継続性確保に必要な技術的対応

  • CGPM（国際度量衡総会） は、2018年の第26回会議で UTCの定義 を再確認

  • UTC は TAI（国際原子時） と同じ速度で進み、整数秒だけ差があることを明記

  • UTC は国際的な基準時刻であり、多くの国で 法定時刻 の基盤

  • 2022年の第27回会議で、 UTCと地球自転時（UT1） の差が整数秒で調整されていることを再確認

  • |UT1-UTC|の許容値 を2035年までに拡大し、少なくとも100年間の UTC継続性 を確保する方針を決定

  • 産業界や 重要インフラ （交通、エネルギー、通信、宇宙事業）では、 連続的なUTC が求められる

  • 一部用途では、 |UT1-UTC|の最大値 を明確化する必要

  • 多くの国では、 現地太陽時と法定時刻 に1時間以上の差があり、 夏時間 でも定期的に1時間の変更が行われている

  • UT1利用者 は、 GNSSナビゲーションメッセージ や IERS、各国計量研究所（NMI） のインターネットサービスで UT1-UTC情報 を取得可能

  • ITU-R は、 UT1-UTCの伝送コード の更新を検討中

    • WRC-23決議655 で、2035年まで（最長2040年）現行機器向けに UT1-UTCの拡大差 の伝送継続を決定

  • 2025年3月のCCTF/IERSワークショップ で、2035年までに 負のうるう秒導入確率が30% に急増と予測

  • 負のうるう秒 はこれまで未導入であり、 重大な障害リスク と評価

    • 産業界の準備コスト はミレニアムバグ対応と同程度と試算

  • IoT、スマートグリッド、仮想サービス等 の普及で、 うるう秒導入時の障害リスク が拡大

    • 特に 負のうるう秒 でリスク増大

  • グローバルサービスプロバイダー による うるう秒対応方法の違い が、 時刻・周波数の不一致 やSI単位との不整合を招く

  • ITU-T、URSI、IEEE 1588等 の国際組織や産業界代表から、 連続的なUTCの早期実現 を求める声明

  • UTC更新の遅れ により、一部ユーザーが GNSS時刻等へ基準変更 するリスク

    • 国際計量標準化 の根幹が損なわれる懸念

  • BIPMとITU-Rの連携強化、 IERSのうるう秒運用変更協力 を歓迎

  • 決定事項

    • 連続的なUTC を 2027年5月20日 から導入
    • |UT1-UTC|の最大値を3600秒（1時間） に設定し、数世紀にわたり UTCの長期継続性 を保証
    • BIPM に対し、 ITU、IAU、IUGG、IERS等 関係機関と連携し、ユーザーへの情報提供・支援を要請
      • UT1-UTCの値のモニタリングと定期報告
      • 地域計量機関、NMI、ユーザーとの協力による連続UTCの理解促進と円滑な提供

  • 公式文書はフランス語版が正本

Hackerたちの意見

さよなら、日時計。セシウム時計、ようこそ！占星術アプリの開発者たちへ：アセンダントのために、特に2267年頃はドリフトを考慮するのを忘れないでね。恋愛運や金運の予測が混乱するかもしれないから。

└

彼らは占星術のサインの日付がずれたことを気にせず、あなたに生まれた時の星座とは関係のない星座を割り当てるから、これについても気にしないんじゃないかなって思う。

コンテキスト：BIPMはUTCの時間基準を担当していて、この文書では2027年5月20日から先の未来にわたって、うるう秒の追加（または削除）をやめることを決定した。12月にうるう秒を追加しない決定と合わせて、これまで追加された27のうるう秒が唯一のものになるはず。ページには、以下のようないくつかの良い理由が挙げられている： - バグの一般的な原因。 - 大まかなタイムゾーンの世界では、太陽時間はそれほど重要ではない。 - IoTや時間更新を受け取れないものは、うるう秒で困る。 - ネガティブうるう秒はこれまで発生したことがないが、将来的には発生する可能性があり、ほとんどのソフトウェアはこのケースをテストしていない。私が追加したいのは： - Unixタイムスタンプは実際には「エポックからの秒数から、発生したうるう秒の数を引いたもの」として定義されている。これは「1日に86400秒」という前提が壊れないようにするためのハック。うるう秒の間はUnixタイムスタンプが戻って前の値を繰り返すため、あいまいで単調ではなくなる。 - うるう秒の予測不可能性は、2つのUTC日付やUnixタイムスタンプの間の秒数を計算するのを不可能にすることがある。例えば、2038年バグのカウントダウン。 - うるう秒のISO8601形式（「23:59:60」）は広くサポートされておらず、パーサーが壊れる。分、時間、日が何秒かという前提も崩れる。 --- 編集：タイトルを変更するために[email protected]にメールを送りました。編集的な表現を避けているけど、投稿が注目されないのも良くないと思う。これで助かる頭痛を祝うために、カレンダーに1秒間の年次休暇を予約しておくよ。うるう秒の終わり、おめでとう！

└
  • うるう秒は、将来のタイムスタンプの時計時間を予測するのを不可能にする。ページにはその理由が載っていないし、将来の壁時計時間はタイムゾーンのルールの変更によって予測不可能なままだ。予測可能になるのは、posix時間と経過時間（TAIの意味で）の関係だけど、少なくとも次の数百年の間はそうだろう。
└

@dan: これを「BIPMがUTCにうるう秒を追加しないことを決定」みたいに名前を変えられないかな？このタイトルは状況を軽視してると思うし、こっちの読者はこれにすごく関心があると思う。こういう@-タグはあまり意味がないから、メールを送った方がいいよ。[email protected]がそのアドレスだと思う。

└
  • ネガティブうるう秒はこれまで発生したことがないが、将来的には発生する可能性があり、ほとんどのソフトウェアはこのケースをテストしていない。FreeBSDは、彼らが管理しているコードに対してこういうのをテストしてるよ：* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... サードパーティのもの（Portsからのもの）はまた別の話。
└

他の読者のためにコンテキストを提供してくれてありがとう。タイトルについてどうするか迷ってたんだけど、私の経験上、編集されたタイトルは最終的に元のタイトルに戻されることが多い。ここでの「実際の」タイトルは「決議5（2026）」だけど、もっと具体的なサブヘッディング「UTCの継続性を確保するために必要な技術的措置」にした。興味深いことに、提出時に「On」が削除された。

└

私の理解は正しい？彼らはUT1という時間を維持していて、これは基本的にうるう秒が続いていたらのUTCなんだよね？

└

リープ時間の可能性なんて、必要になる頃にはもう無理だね。千年以上も硬直化してるから、時計の時間を太陽に合わせることなんて気にしなくなるのが唯一の選択肢だよ。だから、リープ時間について話すのはちょっとジョークみたいなもんだね。こんなアイデアを出してくるなんて驚きだし、もう解決策じゃないって宣言すべきだと思う。

└

これが良いことだってのには同意だけど、リープ秒なしのUTCはもう存在してるよ。それがTAIで、長期的に一貫したテレメトリーを気にするアプリケーションはそれを使ってる。

└

これらの理由を読むと、敗北感を感じるよ。2026年には、時間定義に1秒を追加したり削除したりするような簡単なことすらできないのが悲しいね。リープ秒がなくても時間は存在するわけじゃないし、時間定義を変えるよりもTAIに切り替える方がずっと理にかなってると思う。これからはリープ秒をサポートするUTCコードがたくさん残ることになるし、使われないのに古いUTCと新しいUTCを区別しないといけなくなる。好きじゃないな。

数千年後には、何らかの存在（人間かどうかは別として）が、時間管理についての決定が彼らの生活を難しくしてるバカたちに興味を持つだろうね。神様が望むなら、GoogleやChatGPTはその頃には使われてないだろうけど、彼らはその理由を探るために何らかの検索をするだろう。「一体何を考えてたんだ？」って質問に答えるためにね。もしかしたら、このスレッドはインターネットのデータ収集で永遠にアーカイブされて、当時に見つかるかもしれない。その時には、古代の歴史からこんにちは！正直言って、あんまり考えてなかったよ。私たちは今の便利さに流される怠け者で、問題に対処するのが予防策より10倍大変になるまで現状維持に固執しがちなんだ（君たちがまだ気候を持ってることを願ってるよ！）。それが全てだね。ごめん、みんな。頑張ってね！

Hacker Newsで議論の続きを見る