パスワードを忘れた? アカウント作成
11863577 story
地球

UTC 2015年6月30日に、23時59分59秒の後に23時59分60秒が挿入される 43

ストーリー by hylom
一日が1秒長くなります 部門より
あるAnonymous Coward 曰く、

2015年7月1日にうるう秒が挿入されることが発表された(日本標準時グループGIGAZINE)。

閏秒廃止論は、今回は無しみたいですね。UNIX時間って閏秒はカウントしてないのね、知らなかった。

うるう秒の実施は2012年7月以来で、26回目。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by esuta (40045) on 2015年01月09日 18時24分 (#2741173)

    閏秒 ntp が勝手に吸収してくれるから別に気にしなくてOK
    閏日 さすがに著名なのでどこも対処済み。ていうかライブラリ使えや
    閏月 もしあったらわりと任意っぽいので扱いは大変そう

    かしら

    あともう、春分・秋分の日は100年ぐらいのスパンで決定的にしてしまうほうがいいと思うなー

    • by shibuya (17159) on 2015年01月10日 1時57分 (#2741386) 日記

      >あともう、春分・秋分の日は

      2年先の復活祭の日が確定できないことでカレンダー屋さん、卵屋さんほかの小規模経営がせっせと働く動機を奪わないでそっとしておいてあげるくらいは。。。
      // そもそも日本では春分秋分の日を大義名分にして拠っているお祭りっぽい固有行事少ないわけだし。

      親コメント
    • by Anonymous Coward on 2015年01月13日 13時36分 (#2742703)

      閏秒 → 時間調整のため挿入される秒
      閏日 → 日付調整のため挿入される日
      閏月 → 日付調整のため挿入される月
      閏年 → 閏日や閏月が挿入される年

      閏年だけ仲間はずれ。

      親コメント
    • by Anonymous Coward

      24:00UTCは、09:00JST。JRの座席予約受付開始なんかは10:00JSTだけれども、09:00始業の会社は多少の混乱が起きそう。
      前月の5月31日は日曜日なんだから5月末日の方が良さそうな気がするのだが。なぜだろう?

      • by Anonymous Coward on 2015年01月09日 19時00分 (#2741199)

        うるう秒は、6月末日か12月末日、それでも足りなければ3月末日か9月末日に挿入されるという決まりになっているからです。

        親コメント
      • by Anonymous Coward

        地域によって日付が変わるってこと忘れていませんか? 日曜が公休日でない国もあるし、逆に休日中で無人で動作中にシステム不具合を起こしたら対応するまで時間が掛かるので、「例外的な作業は担当者がいる時に」という見方も。

    • by Anonymous Coward

      > 閏秒 ntp が勝手に吸収してくれるから別に気にしなくてOK

      調べて書いたの?調べもしないで書いたんじゃないの?

      ntp がリアルタイムに時間を調整するから危険が増えます。
      http://pocketstudio.jp/log3/2012/06/23/leaptime_2012/ [pocketstudio.jp]

      ntp がリアルタイムに時間を調整しても問題があるかどうかで
      問題があるならばntpを止めるかモードを変えましょう。

      • by Anonymous Coward

        調べるのは構いませんが,ntpの仕組みが理解できてませんよwww

        > ntp がリアルタイムに時間を調整するから危険が増えます。

        間違ってます

        ntpは安全に時間を調整する仕組みです

        元コメントのほうが正しくて
        ntpのデフォルトの挙動が「勝手に吸収してくれる」です

        • by Anonymous Coward

          > 間違ってます
          > ntpは安全に時間を調整する仕組みです

          へー。
          デフォルトモードでも時間を遡りしないっていう資料をください。

          • by eukare (2230) on 2015年01月10日 16時37分 (#2741602) 日記

            ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。
            プロトコル自体には閏秒の扱いは規定されてる。

            親コメント
            • by Anonymous Coward

              > ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。
              > プロトコル自体には閏秒の扱いは規定されてる。

              で、そのプロトコルに従ってリアルタイムに時刻を変更されると問題が発生する可能性があるみたいですね。

              >> ntp がリアルタイムに時間を調整するから危険が増えます。
              >間違ってます

              「ntp がリアルタイムに時間を調整するから危険が増え」るのは間違いないと思うんだけどな。

          • by Anonymous Coward

            環境や要件によって,精度(マイクロ秒まで考慮するか否か)や挙動(60秒を許すか否か)など「調整」や「吸収」の定義が違うのに,殴り合ってどうするのですか。

            • by ymasa (31598) on 2015年01月10日 15時29分 (#2741563) 日記

              だから

              > ntp がリアルタイムに時間を調整しても問題があるかどうかで
              > 問題があるならばntpを止めるかモードを変えましょう。

              と書かれていると思うんだけどな。

              親コメント
            • by Anonymous Coward

              > 環境や要件によって,精度や挙動など「調整」や「吸収」の定義が違うのに

              安全って言えるんですね?って話だろう?

              > 元コメントのほうが正しくて
              > ntpのデフォルトの挙動が「勝手に吸収してくれる」です

              はウソだし

              > ntpは安全に時間を調整する仕組みです

              もウソじゃない?

              って思います。

        • by Anonymous Coward

          2012年に痛い思いをしているのでいろいろ安心なんてできません・・・・
          あのあとLinuxカーネルのパッチでたからもう大丈夫。とは思いたいけど。

          • by Anonymous Coward

            でもその後実際に働いた実績が無いわけですよね。今度はカーネルは大丈夫だったけどアプリ側が独自に時刻管理していたのが嵌ったとかあるかも。
            故あってUpdateがままならないやつが数十台規模であるんだけど、ntpdはslowモードにしておいたほうがよさそうだな。

    • by Anonymous Coward

      4年に1回しか実装していなくて2100年問題(2000年は400の倍数だったのでたまたま踏まなかった)を抱えたプログラムがありそう。

  • by Anonymous Coward on 2015年01月09日 18時41分 (#2741187)

    > 閏秒廃止論は、今回は無しみたいですね。UNIX時間って閏秒はカウントしてないのね、知らなかった。
    むしろ今年が山場で、11月にITUが開催されるWRC-15で決定されます。

    この文書(PDF) [itu.int]のP9・10に記載されており、
    方針としては以下の3つがあります。

    Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)
    Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる
    Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)

    Method Bになったら、いろいろ悪夢です。

  • by the.ACount (31144) on 2015年01月10日 12時46分 (#2741490)

    日常生活に影響するほど乖離するまで人類存続しないということ?

    --
    the.ACount
    • by Anonymous Coward

      どっかの国が世界覇権国家になって、「おらの国の首都が世界の中心線だべ」と時刻の定義を書き直すほうが先かなぁ

  • by Anonymous Coward on 2015年01月09日 18時18分 (#2741171)

    26回目もうるう秒を挿入しなきゃいけないなら、1秒の定義をほんの少しだけ長くしたらいいのに。
    短い方に補正した例はないんだから。

    • 今後短い方に補正する可能性はゼロではないですね・・・自転周期は地球の構造上中心部が液体であること、潮の干満と海底との摩擦により、長期的には自転速度はだんだん遅くなっています [wikipedia.org]し、そもそも自転周期は不規則に変動している(一定ではない)ので、「閏秒が必要ないように」かつ「現在の各種インフラを維持できる精度で」定義を変えるというのは難しいでしょうね。
      地球の自転周期で1日を定義しようとすると、10^-8日(*60*60*24≒ミリ秒)程度の精度しかないそう。
      なお、抜く必要が出る頃に人類が地球上にいるかは私にはわかりかねますが。

      親コメント
    • by Anonymous Coward on 2015年01月09日 18時34分 (#2741183)

      うるう秒は測定誤差から来てるんじゃなくて、地球自体の回転の鈍化が原因。

      だから、今の回転速度に合わせて秒の長さを再定義しても、何年か経ったらまたうるう秒を挿入しなければいけない。さすがにそれは筋が悪すぎる。

      親コメント
      • by Anonymous Coward

        >地球自体の回転の鈍化が原因。

        それ、誤解。
        今後の長期的観測を待たないと断定的なことは言えないけど、近年の地球の自転速度はむしろ早まってます。

        仮に「一日に2秒進む時計」があったとして、一月に一度1分戻し続けなければズレが溜まってしまうわけで、
        今はそういう状態。
        この進みが「一日に2.1秒」、「一日に2.2秒」… と増えていくのであれば「自転の鈍化」言えますが、
        近年の観測ではむしろ「一日に1.9秒」、「一日に1.8秒」… と時計の進みが減っている傾向です。
        このままの状態が続けば、徐々に閏秒を挿入する間隔は長くなり、長期にわたる「閏秒不要の時代」を経て、
        いずれ「閏秒の削除時代」がくるかもしれません。

        「自転速度の鈍化」がなくても、一定のズレがあり続けるだけで、閏秒挿入の必要もあり続けます。

        • by Anonymous Coward

          ここ [wikipedia.org]には「地球の自転は減速傾向にある」と書かれているのですが
          加速しているというのはどの文献ですか?

          • by Anonymous Coward

            その ここ [wikipedia.org]に「ここ40年間では、一日の長さ(LOD)はむしろ短くなっている(地球自転速度が速くなっている。)」と。
            まあ、1秒の基準にした頃よりは回転が鈍化しているというのは違いないが、グラフ [ucolick.org]を見ると1972年頃が一番速かったようです。
            しかしなぜ1956年に秒の長さを決めたときに、その時点でのLODではなく1750年から1892年までが基準になったんだろう?
            その頃は鈍化中だったので、過去に遡った基準点にする

            • by Anonymous Coward

              訂正。(図中では)1972年頃が一番遅く、速いのは2004年頃でした。

    • by Anonymous Coward

      暦 の秒の定義だけ変えちゃったから仕方ない。
      元が地球一回転基準ですからねぇ。

      最終的には回転速度調整しかありませんな。

      • by Anonymous Coward

        宇宙エレベータをいっぱい作ったら...
        遅くする方にしか調整できないか。

  • by Anonymous Coward on 2015年01月09日 18時26分 (#2741176)

    2015年6月30日にうるう秒が挿入されることになりました。
    通常のシステムでは、秒は0~59までの値を取る前提に作成されていますが、これに60という数字が入ることにより、
    御社のコンピュータシステムが誤作動する可能性があります。
    最悪の場合、システムの停止、データの喪失、データ化けが発生し、
    取り返しのつかない状況になる場合がございます。

    当社では、他社の作成したシステムでも、格安で改修を行っております。
    調査・改修の見積もりは、下記の電話で受け付けております。
    すぐにお電話ください。

    会社名: あやしいシステム
    TEL: 090-xxxx-xxxx

    • by Anonymous Coward

      60進数の言語環境とか、何の役に立つと思って設計したんだろう。

      あっ...

  • by Anonymous Coward on 2015年01月11日 11時37分 (#2741891)

    0時0分、丁度を、おしらせします。…ぴ、ぴ、ぴ、ぽーん、ぽーん…とか、ぽーんが2個入るのかな?だれか聞いた人いませんか?

  • by Anonymous Coward on 2015年01月11日 12時42分 (#2741905)

    通常存在しない60秒という時刻を挿入するのと、59秒を2回やるのでは、どっちの方がシステムに与える影響が少ないんですかねえ。

    • by Anonymous Coward

      時刻をキーにしているDBがありそうだから、59秒が2回刻まれるの方が痛いかと。
      むろん、60秒を例外扱いしないよう組んである必要がありますが。

      • by Anonymous Coward

        それが為に59秒が2回刻まれるとまずいことが起こるなら、1秒以内に2回そのイベントが起きないことが保証されていることが必要。
        1秒以内に2回起きないことは保証していて、2秒以内に2回起きないことは保証できないといのは限定的だと思う。
        でも、59秒が2回刻まれると秒未満での時刻の遡行が起こるので重大な影響になる(2012年には実際起きたようで)。
        一方、time構造体中の秒は古えより「int型の0~60」と定義されているので、よもや60秒を考慮していないなんてない。はず。きっと。多分。だといいなぁ。

typodupeerror

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

読み込み中...