パスワードを忘れた? アカウント作成
1416999 story
スラッシュバック

うるう秒廃止、ITUが決定を延期 46

ストーリー by headless
うるわず 部門より
うるう秒の廃止について協議した国際電気通信連合(ITU)の無線通信総会(RA-12)は、さらなる調査が必要として決定を延期した(ITUのプレスリリースtimeanddate.comの記事AFPBB Newsの記事asahi.comの記事)。

うるう秒の廃止についてはITU-Rの研究グループがUTCの再定義に関する勧告をまとめており、RA-12で勧告の是非について投票を行う予定になっていた(/.J記事)。しかし、主要国の賛否が別れた上、問題を理解していない国もあるとして採決は行われず、2015年の会合で再度協議することになったとのこと。うるう秒の廃止については、23日からジュネーブで開かれるWorld Radiocommunication Conferenceでも議題に上る予定。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by u1p (2709) on 2012年01月21日 15時03分 (#2084776) 日記
    > 問題を理解していない国もあるとして

    どこか教えてくれー。
    そのくせ軍事とか方面で科学大国だったら怒るぞ。

    # 日本が賛成だから、反対って国はさすがに無いよね?
  • AFPBB News [afpbb.com]

    同連合はこれまで40年間、このうるう秒で「協定世界時(Universal Coordinated Time、UTC)」の調整を行ってきた。(中略)うるう秒が廃止されれば原子時計は太陽時より100年間で15秒進むことになるという。(中略)うるう秒の挿入はITUが協定世界時を設定して以来、24回行われた。

    40年間で24回=24秒ずれたのに、今後100年でずれるのは15秒という予測。なんと、2000年を境に地球の自転の変化速度が「がくっと」変化しているのだった。朝日の記事 [asahi.com]内の図で分かる。知らなかった話だけど、西暦500年頃と西暦900年頃に自転速度が急激に変化した事もあるとか(Wikipedia [wikipedia.org])。地球内部で何か起きてる?

    • by Anonymous Coward

      ジャイアントインパクト他による月の生成以降、地球の自転は潮の満ち引きなどを通じて月の公転に転換され続けています。
      地震・天体衝突等の特殊要因をのぞいて、地球の自転速度は低下し続けており、月が失われない限り今後も続いていきます。
      (たとえ月が失われようと、その他の天体との相互作用により、僅かに低下します)

    • by Anonymous Coward

      出っ張っていた部分が引っ込むと、回転の運動エネルギー(とモーメント)に直結しているわけだから、径が減るほど速くなる。フィギュアスケートの選手が手を引っ込めるように。

      • ここでコメントします。何しろよく分からないんですが、

        1)地球の自転速度は昔から徐々に遅くなっている。ただ、2000年頃を境に、遅くなるスピードが鈍化したように見える、というか専門家は今後もそのままと予測しているようである(あるいはもう少し、遅くなるのが、遅くなる)。

        2)2010年のチリ地震で1.26μ秒、2004年のスマトラ島沖地震で6.8μ秒、2011年の東北地方太平洋沖地震で約1.8μ秒、自転速度が増したらしい(Wikipedia [wikipedia.org])。365日に直すと、スマトラ島沖の場合、6.8マイクロ秒×365=2.482ミリ秒。1年で0.002秒程度では、影響として小さすぎる。

        3)40年間で24秒遅くなったのなら、平均1.66年で1秒遅くなった計算。もっともグラフを見ると、
         1970年→1980年で10秒、
         1980年→1990年で6秒、
         1990年→2000年で8秒、
         2000年→2010年で2秒、
        遅くなっている。これだと、1年に1秒遅くなるのが通常で、そこに何らかの増速ファクターが関与したような気がしないでもないが...

        親コメント
  • by Anonymous Coward on 2012年01月21日 15時30分 (#2084793)

    そもそも、うるう秒を挿入する予定日は、「実施日は協定世界時(UTC) の月末とされ、年12回の可能性があるが、第一優先が6月末日または12月末日、第二優先が3月末日または9月末日」で、挿入する時刻も「実施日23時59分台の末尾」と決まっているから、NTPサーバーにアクセスして時計あわせをするタイミングとして、その日時を避けるようにしておけば、たいていの用途では問題ないと思うんだけど・・・

  • 誰も気が付かないと思うし。

    ところで、水晶発信器メーカーのエプソンのリアルタイムクロックICは、もともと32768Hzのかなり正確な水晶発振子を内蔵していますけど、精度の水晶発振子といえども個体ごとの固定的な偏差はあるので、IC内には、32768Hzの原信号から1秒をつくる分周器に「ある一定のタイミングで、1秒の長さを1/32768秒単位で伸ばししたり縮めたりする機能」が内蔵されていて、各ICごとにバラつきを校正できるようになっていました。

    たしか、コンピュータの時刻関数でも、同様な手法でうるう秒をなだらかに吸収しているものがありましよね?

    • 普通にUTCじゃなくてUT1を使えばいいだろ。
      親コメント
    • 時報方式?(電話の時報は1分前から1/60秒ずつ長くしてうるう秒の挿入に対応してたはず)
      60秒の存在がまずいのでなければ,1秒ずれるという結果は同じなので,取り立てて効果は期待できないんじゃ?って思ったり。

      親コメント
      • by Anonymous Coward

        時報方式?では、1分40秒前から、1/100秒づつです。

    • by Anonymous Coward

      って一秒の定義を変えたらダメだろ。ミリ秒単位で調整してたら回数ばかり増えてよけい面倒になる。
      いままでどおりマメに1秒以内におさえるか、数十年に一回1分ずつにするか、1時間単位で調整するか、
      「それとも調整自体をやめちゃおうか?」話なんだから。

      わかってない国だなって言われちゃうぞ。

    • 2/29(うるう年)、うるう秒、サマータイムの処理いずれもなんですが、
      基準となる日時から時刻を求める計算式で吸収すべきで、時間の長さを
      変えてはいけません。

      そういう時刻補正のパラメータは、定義に従って見える形で補正してあげないと、
      ログとか時刻を特定しなければならない情報が破たんしてしまいます。

      ちなみにIBMおよびその互換メインフレームでは、何十年も前からH/W内部に
      ローカルタイム、サマータイムやうるう秒補正用のテーブルを設定できるように
      なってますね。

  • by Anonymous Coward on 2012年01月21日 14時48分 (#2084771)

    まず基本的なうるう年処理で
    誤作動を起こさないシステムを作ってください

    #なんで2/29を考慮しないシステムが多いのだろう?

    • by Anonymous Coward

      考慮しないというか忘れているのではないだろうか。

    • by Anonymous Coward

      2000年はルール上、400年に一度の年だったからしょうがない。

      • by Anonymous Coward
        普通のシステムで100年以上動かす事なんて滅多に無いだろうから、ただ「4で割り切れたら閏年」の処理だけをやっていればそれで良かった。

        なんで「100年に一度」まで考慮していながら「400年に一度」まで考慮しないのか不思議。しょうがないとは思えないしょうがなさ。
        • だいぶ昔の話になるけど、一緒に仕事をしてた人がmktime相当の処理を書くときに、
          ある和訳本に書いてあるコードを丸写ししたら思いっきり2000年は閏年でなかったということがありました。
          その本にあるコードにはきっちりコメントで2000年は閏年でないと書いてあって、
          丸写ししたコードのコメントをたまたま読んだ顧客がそれに気がついたというみっともなさ。

          # コメントまで丸写しとは律儀ではある。

          なんでそうなったのか当時調べてみたら、米国でその辺がすっぽり忘れられて教育されていたとか何とかあったと記憶してます。
          有名な本か教科書かが間違ってたとか何とか。

          で、Y2K問題以前は多くの米国人は2000年は閏年ではないと思っていたと、私は勝手に思ってます。真実は知らないけど。

          親コメント
        • by Anonymous Coward

          >100年以上動かす事なんて滅多に無いだろう

          ではなくて、多くのクリティカルなソフトウェアでは、仕様に設計寿命が含まれていたから、限られた資源の中で、考慮しなかった。

          設計寿命30年のシステムを1960年代に作ったとして、まさか2000年を迎えるなんて想定外だったわけです。

          東京電力はこんなことも言ってますが、
          http://www.tepco.co.jp/nu/qa/qa15-j.html [tepco.co.jp]

          • by Anonymous Coward
            理解してないでしょ。

            2000年まで使うことを想定していなくても、
            2100年まで使うことは無いと想定すれば、
            「4で割り切れれば閏年」とうい処理だけをインプリメントしておけばよかった、という事。
            それだけで正しく2000年は閏年として処理された。
            という事。

            #いわゆる2000年問題は別ね。
            • by Anonymous Coward

              2000年と2100年が逆?
              2000年まで使う事を想定していなければ2100年を想定していないのは当然だけど。

          • by Anonymous Coward

            そもそも、

            稼働期間 = 扱う日付の範囲

            ってシステムのほうが少ないだろうが。

            • by Anonymous Coward
              それ意味ない。

              扱う日付の範囲の想定が、具体的にどの範囲だったら、
              「100年に一度の処理を入れるけど400年に一度の処理を入れない」なんていう事になるというの?

              過去100年分以上の日付は扱うけど現在より先の日付は扱わないとかなら、まだわかるけど。
    • by Anonymous Coward

      富士通とか富士通とか富士通とかのLSIですね。
      恨みは今でも忘れない。

    • by Anonymous Coward

      四年に一回くらいの不具合で文句をいうでない。
      一日一回の処理でさえ不具合を出すプログラマーが珍しくないというのに。
      金をけちれば品質が落ちるのは当然なのよ。

      #1分に1回のアクセスで機能不全に陥る図書館は……あれは、ちょっと別路線か。

  • うるう秒を逐次行なっていたら、自ずと対策は取られる。
    うるう秒を廃止して数100年後、ど~んと協定世界時を天文時に合わせ直すとき、また2000年騒動の様なお祭り騒ぎが繰り返される。
    馬鹿じゃないだろうか。
    鎖国して武装解除して技術進歩を否定した、初期江戸幕府首脳部並みの脳足りんか。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...