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

Windows 10/Server 2019、うるう秒サポートへ 66

ストーリー by headless
追加 部門より
Windows Server 2019には、うるう秒サポート機能が搭載されるそうだ(Networking Blogの記事Ars Technicaの記事Neowinの記事The Registerの記事)。

うるう秒を挿入せず、長時間かけて1秒分の誤差を吸収するleap smearingによる対応はこれまでも批判されていたが、米国や欧州では時刻同期の誤差に対する規制が強化されたため、利用場所によってはleap smearingを適用すると基準を満たさないこともある。

そのため、Windows Server 2019ではleap smearingのオプションを搭載せず、うるう秒を実際に挿入する処理が行われる。つまり、うるう秒挿入日は日本時間で8:59:59と9:00:00の間に8:59:60が挿入されることになる。また、これまでに適用されたことはないが、負のうるう秒にも対応する。この場合は8:59:59が飛ばされ、8:59:58の1秒後が9:00:00となる。

Windows 10も今後のRS5アップデート(バージョン1809)で、うるう秒がサポートされるようになるとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 日付時刻型もうるう秒対応するのかな?

    • by Anonymous Coward on 2018年07月22日 15時02分 (#3447120)

      そりゃ対応するでしょ。そして「60」秒が返ってきてそこら中で例外発生よ

      親コメント
      • by Anonymous Coward

        秒が60を返してきただけで例外が発生するようなことってあるか?

        • by Anonymous Coward

          そのへんの言語仕様も変えちゃうんじゃないかなー
          でもって8:00=on&&on=8:59:59
          みたいな書き方をしていると8:59:60にヤッたことが全部漏れると

        • by Anonymous Coward

          世の中「んな馬鹿な」と思う条件で問題が起きるんですよ!

          • by Anonymous Coward

            疲れていたとか検討する時間が不十分だったとかはんな場かなと思う条件?
            //==と=を間違えたことはあるし==と===を間違えたこともある

        • by Anonymous Coward

          例えばint data[60];で60秒分の配列用意してあったら、data[60]に代入しようとして死亡。

        • by Anonymous Coward

          日付時刻型クラスがどうなるかですね。
          ログや通信データに08:59:60が有った時にパースで落ちなければ良いですが。
          他にも加算、減算で60の扱いがどうなるとか。

          メーラーとかブラウザとかヘッダの時刻が正しく取り扱いしてくれるか再確認が必要かも。

          今回Windows Serverがこうなりましたけど、AzureやAWSとかの米国にあるLinuxサーバーやサービスとかもうるうをぶっこんでんでくる可能性があるって事で対岸の火事ではいられない可能性が。

          • manページには、struct tmのtm_secは、閏秒のために「60」が設定される可能性があると明記してあるので、システムとして想定済みではあるんでは。

            親コメント
          • by Anonymous Coward


            PowerShell> ([datetime]'2018/07/23'-[datetime]'2018/07/22').ToString()

            が、普通は'1.00:00:00'になるんだけど、うるう秒跨ぐ時はどうなるんだろうなー。
            やっぱ'1.00:00:01'だろうな、きもいなーw。
            2017年とか過去のうるう秒も存在した値で返るようになんのかな。

          • by Anonymous Coward

            規制強化が理由だから入るでしょうね。
            「一分は60秒」が崩れるってキツイなぁ。

            クラスはプロパティオーバーロード追加かなぁ?デフォルトどうする?で揉めそう。。

            これ、混在せざるを得ない辺りが厄介ですね。接続先が違う時間軸あり得るとかシャレにならない。

            • by Anonymous Coward

              「一分は60秒」が崩れるってキツイなぁ

              表現が難しいのだけど、うるう秒がはいったとしても、時間としての1分は60秒のままだよ。
              あくまで、うるう秒がある場合にうるう秒の情報がないと、ある時刻と時刻の間の時間が不定になる、というだけ。

              • by Anonymous Coward

                何いってんの?一日の秒数は変わるのよ。
                こんなんばかりだとそら混乱するわな。

              • by Anonymous Coward

                時間単位としての1日は86400秒で不変です。
                「暦日の長さ」が(時間単位としての)1日(=86400秒)でなくなるだけです。

                うるう秒の挿入に関係なく「暦日の長さ」は変動するものです。
                というより変動の結果としてうるう秒が挿入されるのです。

      • by Anonymous Coward

        OSSの中には、内部処理をUNIX Timeで実装しているようなものもたくさんあるだろうし、そういう場合に、その辺の変換がどうなるのかは気になる。

    • by Anonymous Coward

      .Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。
      既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。
      既存のいろんなところでDateTime使っているけどそれは多分そのままかな。
      厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。
      うるう秒はDateTimeにすると表現できないし、
      DateTimeは内部ではInt64を使っているらしいから仮

      • by Anonymous Coward

        おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。
        内部形式のInt64のデータには何も変更がないでしょう。

        • by Anonymous Coward

          そのあたりは新元号対応と同じでしょうね。

        • by Anonymous Coward

          内部データに手を入れないならParse()で60秒を翌0秒とみなすだけで十分かと。

        • by Anonymous Coward
          DateTimeのリファレンスコードをざっと確認したのですが、内部形式のInt64データ自体にうるう秒が入っていない可能性が高いので、そう簡単にはいかなそうです。
          • by Anonymous Coward

            どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。
            Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。

        • by Anonymous Coward

          Ticksの問題もあるからそんな単純ではない。

    • by Anonymous Coward

      きっと、レジストリに閏秒の一覧表でも登録するようになるのだろう。

  • ついでにRealTimeIsUniversalでUTCを使っていても標準でNTCサーバと同期してくれると嬉しいなぁ。

    • by Anonymous Coward

      その前にファイルシステム(NTFS ?)も、閏秒に対応してもらわなければ。

      • by Anonymous Coward

        NTFSでは1601年1月1日0時0分からの100ナノ秒単位でタイムスタンプを計算しているので、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。内部形式には何も変更がないでしょう。結果として、タイムスタンプの値自体は変わっていないのに、文字表記すると数秒変わってしまうことになる。

  • by Anonymous Coward on 2018年07月22日 15時57分 (#3447138)

    あちらこちらでいろんなサービスに障害が起こりそうだなぁ・・

    • by Anonymous Coward

      仕様変更にころっともクソもないだろう
      コロコロ変わるのは別ですが買えるときはコロッとなりサクッとなり変えるしかない

  • by Anonymous Coward on 2018年07月22日 18時59分 (#3447175)

    誰が批判してたのかしらんが、そいつは馬鹿だから相手にしなかったMicrosoftは賢かったな。
    もともと信頼性の低いPCのクロックとネットワークによる誤差の避けられないNTPを使っている今の仕組みで、うるう秒なんて迷惑でしかない。

    規制当局の要求なら仕方ないが、政府機関はろくなことしないなという感想しかない。

    • by Anonymous Coward

      時刻の送出側ならまだしもそのへんの機械でうるう秒に対応したってねぇ……

      放っておけば一月も経たずに1秒なんてずれるわけで。

    • by Anonymous Coward

      今はもう時刻が認証の要素に使われる時代ですぜ。
      正確さを要求されているのもそっち方面でしょう。
      時代の流れですよ。

      • by Anonymous Coward

        今は?
        Kerberos認証がWindowsで使われるようになってから何年経ったと思ってんの

        • by Anonymous Coward

          最近は200ppmとか普通に要求されるよ。

        • by Anonymous Coward

          NTPの話をしているんだから、許容誤差が5分もあるサービスの話をしていないことは明らかだろうに・・・

    • by Anonymous Coward

      単に「マイクロソフトがやる事だけ」は全て批判すべきモノにしたいんでしょう。

      ntpd(等)のslewはキレイなslew
      マイクロソフトのは汚いslewと。

  • 一日の長さが微妙に変わったケースはあまり見た事がない。

    • by Anonymous Coward

      生活リズムがめちゃくちゃな(昼寝必須)の主人公が
      1日が12時間の世界に転移して生活リズムと活躍のリズムが絶妙で俺ツエーですか?

      なんじゃそりゃ。

      というのは置いておいても、主人公が
      「ここって一日12時間*じゃん!」って
      どうやって気づくんでしょう。(*12時間以外の微妙な時間でも可)

      電波式腕時計・NTP時間設定型端末・GPS時間設定型端末では成り立たないですし、
      電池式駆動端末(スマホ・腕時計を含む)だと気づく前に停止しそうですし。

      ・機械式腕時計をはめていた
      ・ソーラー駆動の非電波式腕時計をはめていた

      高校生・大学生にはあり得ない想定ですねぇ
      まあ、機械式腕時計はめてそうな中年サラリーマンが異世界転生系もあるのでどうとでもできますが
      あ、いかん「昼寝必須の中年サラリーマン」が別の意味でありえん。

      • by Anonymous Coward

        その辺の主人公ならソシャゲで鍛えられた絶対時感を持ってい(る設定があっ)てもおかしくない!

        # 腕時計の電池はアホみたいにもつんじゃなかろうか

      • by Anonymous Coward

        電池駆動式の腕時計って、アナログでも年単位、デジタルだと(個体差はあるにしても)十年とか、結構持ちますよ。

      • by Anonymous Coward

        異世界でも物理定数は変わらないのかとか、そういった検証や設定まで突っ込み出したらキリがなんじゃないかな?

        • by Anonymous Coward

          物理定数を検証する云々て題名のラノベあったけど面白くなかった

          結局魔法あるそうだけどどないだに走ってた

          物理定数変わるくらいなら計測器なんて時計からして信用できんはずなんだが
          そこは置いといて測れていた

          まあ酸素足りない異世界と一緒で出オチのショートショートにしかならんだろうけど

          • by Anonymous Coward
            1巻の1章だけは面白かったやん…
            いろいろ有り物組み合わせて各種物理定数を検証してて
          • by Anonymous Coward

            理系が恋に落ちたので証明してみた。

        • by Anonymous Coward

          物理定数が変わったのと等価な気がする有名SFを知ってるけど、あれは異世界に意識的に行ってるから転移系ではないな・・・
          #れっつごー 中性子星! いざゆかん、チーラの住む星へ!

      • by Anonymous Coward

        どうやって気づくんでしょう。(*12時間以外の微妙な時間でも可)

        そこまで極端だと普通は何かおかしいと思うわけだが、それに気付かない主人公の超適応能力とか?

        電波式腕時計・NTP時間設定型端末・GPS時間設定型端末では成り立たないですし、

        むしろ神懸かりなデンパを受信して云々とか?

        電池式駆動端末(スマホ・腕時計を含む)だと気づく前に停止しそうですし。

        魔力駆動式になってて(よくある)、アプリ開発して魔道具化して(たまにある)

        ・機械式腕時計をは

    • by Anonymous Coward

      マンガでは20年ぐらい前に描かれた、なかざき冬のIN23H なんてのがありますね

    • by Anonymous Coward

      たくさんあるけど、

      秒から分程度
      実影響がない。なので描写がない/意味がない。

      1時間以上
      影響というか、「xxxを考慮してyyy」の描写はする、たまに必要な時間までの日数の差で「間にあわないから大変だ!」な話になったりする

      くらいだね

  • by Anonymous Coward on 2018年07月23日 1時58分 (#3447310)

    失われた情報は復元できないのだから
    内部表現ではうるう秒の存在を無視しないでほしい。
    それを踏まえてうるう秒の挿入として処理するかleap smearingとして処理するかは
    より上位の層が考えればよい話。

    そもそも時刻の正確度と時間の正確度のどちらが要求が高いかといえば
    ほとんどのアプリケーションで後者だと思う。
    時刻の表示が1分ずれたところで何が困るというのか。

typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...