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)で、うるう秒がサポートされるようになるとのことだ。
うるう秒を挿入せず、長時間かけて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)で、うるう秒がサポートされるようになるとのことだ。
.Net FrameworkやSQL Serverはどうなる？ (スコア:2)
日付時刻型もうるう秒対応するのかな？
Re:.Net FrameworkやSQL Serverはどうなる？ (スコア:4, 興味深い)
そりゃ対応するでしょ。そして「60」秒が返ってきてそこら中で例外発生よ
Re: (スコア:0)
秒が60を返してきただけで例外が発生するようなことってあるか？
Re: (スコア:0)
そのへんの言語仕様も変えちゃうんじゃないかなー
でもって8:00=on&&on=8:59:59
みたいな書き方をしていると8:59:60にヤッたことが全部漏れると
Re: (スコア:0)
世の中「んな馬鹿な」と思う条件で問題が起きるんですよ！
Re: (スコア:0)
疲れていたとか検討する時間が不十分だったとかはんな場かなと思う条件？
//==と=を間違えたことはあるし==と===を間違えたこともある
Re: (スコア:0)
例えばint data[60];で60秒分の配列用意してあったら、data[60]に代入しようとして死亡。
Re: (スコア:0)
日付時刻型クラスがどうなるかですね。
ログや通信データに08:59:60が有った時にパースで落ちなければ良いですが。
他にも加算、減算で60の扱いがどうなるとか。
メーラーとかブラウザとかヘッダの時刻が正しく取り扱いしてくれるか再確認が必要かも。
今回Windows Serverがこうなりましたけど、AzureやAWSとかの米国にあるLinuxサーバーやサービスとかもうるうをぶっこんでんでくる可能性があるって事で対岸の火事ではいられない可能性が。
Re:.Net FrameworkやSQL Serverはどうなる？ (スコア:2)
manページには、struct tmのtm_secは、閏秒のために「60」が設定される可能性があると明記してあるので、システムとして想定済みではあるんでは。
Re: (スコア:0)
PowerShell> ([datetime]'2018/07/23'-[datetime]'2018/07/22').ToString()
が、普通は'1.00:00:00'になるんだけど、うるう秒跨ぐ時はどうなるんだろうなー。
やっぱ'1.00:00:01'だろうな、きもいなーw。
2017年とか過去のうるう秒も存在した値で返るようになんのかな。
Re: (スコア:0)
規制強化が理由だから入るでしょうね。
「一分は60秒」が崩れるってキツイなぁ。
クラスはプロパティオーバーロード追加かなぁ？デフォルトどうする？で揉めそう。。
これ、混在せざるを得ない辺りが厄介ですね。接続先が違う時間軸あり得るとかシャレにならない。
Re: (スコア:0)
「一分は60秒」が崩れるってキツイなぁ
表現が難しいのだけど、うるう秒がはいったとしても、時間としての1分は60秒のままだよ。
あくまで、うるう秒がある場合にうるう秒の情報がないと、ある時刻と時刻の間の時間が不定になる、というだけ。
Re: (スコア:0)
何いってんの？一日の秒数は変わるのよ。
こんなんばかりだとそら混乱するわな。
Re: (スコア:0)
時間単位としての1日は86400秒で不変です。
「暦日の長さ」が(時間単位としての)1日(=86400秒)でなくなるだけです。
うるう秒の挿入に関係なく「暦日の長さ」は変動するものです。
というより変動の結果としてうるう秒が挿入されるのです。
Re: (スコア:0)
OSSの中には、内部処理をUNIX Timeで実装しているようなものもたくさんあるだろうし、そういう場合に、その辺の変換がどうなるのかは気になる。
Re: (スコア:0)
.Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。
既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。
既存のいろんなところでDateTime使っているけどそれは多分そのままかな。
厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。
うるう秒はDateTimeにすると表現できないし、
DateTimeは内部ではInt64を使っているらしいから仮
Re: (スコア:0)
おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。
内部形式のInt64のデータには何も変更がないでしょう。
Re: (スコア:0)
そのあたりは新元号対応と同じでしょうね。
Re: (スコア:0)
内部データに手を入れないならParse()で60秒を翌0秒とみなすだけで十分かと。
Re: (スコア:0)
Re: (スコア:0)
どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。
Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。
Re: (スコア:0)
Ticksの問題もあるからそんな単純ではない。
Re: (スコア:0)
きっと、レジストリに閏秒の一覧表でも登録するようになるのだろう。
OSの時刻周りに手を入れるなら (スコア:2)
ついでにRealTimeIsUniversalでUTCを使っていても標準でNTCサーバと同期してくれると嬉しいなぁ。
Re: (スコア:0)
その前にファイルシステム（NTFS ?）も、閏秒に対応してもらわなければ。
Re: (スコア:0)
NTFSでは1601年1月1日0時0分からの100ナノ秒単位でタイムスタンプを計算しているので、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。内部形式には何も変更がないでしょう。結果として、タイムスタンプの値自体は変わっていないのに、文字表記すると数秒変わってしまうことになる。
OSの根幹の仕様がコロっと変わるのか (スコア:0)
あちらこちらでいろんなサービスに障害が起こりそうだなぁ・・
Re: (スコア:0)
仕様変更にころっともクソもないだろう
コロコロ変わるのは別ですが買えるときはコロッとなりサクッとなり変えるしかない
「これまでも批判されていた」？ (スコア:0)
誰が批判してたのかしらんが、そいつは馬鹿だから相手にしなかったMicrosoftは賢かったな。
もともと信頼性の低いPCのクロックとネットワークによる誤差の避けられないNTPを使っている今の仕組みで、うるう秒なんて迷惑でしかない。
規制当局の要求なら仕方ないが、政府機関はろくなことしないなという感想しかない。
Re: (スコア:0)
時刻の送出側ならまだしもそのへんの機械でうるう秒に対応したってねぇ……
放っておけば一月も経たずに1秒なんてずれるわけで。
Re: (スコア:0)
今はもう時刻が認証の要素に使われる時代ですぜ。
正確さを要求されているのもそっち方面でしょう。
時代の流れですよ。
Re: (スコア:0)
今は？
Kerberos認証がWindowsで使われるようになってから何年経ったと思ってんの
Re: (スコア:0)
最近は200ppmとか普通に要求されるよ。
Re: (スコア:0)
NTPの話をしているんだから、許容誤差が5分もあるサービスの話をしていないことは明らかだろうに・・・
Re: (スコア:0)
単に「マイクロソフトがやる事だけ」は全て批判すべきモノにしたいんでしょう。
ntpd（等）のslewはキレイなslew
マイクロソフトのは汚いslewと。
（日本国）異世界転移系の（ネット）小説はあれこれあるけど (スコア:0)
一日の長さが微妙に変わったケースはあまり見た事がない。
Re: (スコア:0)
生活リズムがめちゃくちゃな（昼寝必須）の主人公が
1日が12時間の世界に転移して生活リズムと活躍のリズムが絶妙で俺ツエーですか？
なんじゃそりゃ。
というのは置いておいても、主人公が
「ここって一日12時間＊じゃん！」って
どうやって気づくんでしょう。（*12時間以外の微妙な時間でも可）
電波式腕時計・NTP時間設定型端末・GPS時間設定型端末では成り立たないですし、
電池式駆動端末（スマホ・腕時計を含む）だと気づく前に停止しそうですし。
・機械式腕時計をはめていた
・ソーラー駆動の非電波式腕時計をはめていた
高校生・大学生にはあり得ない想定ですねぇ
まあ、機械式腕時計はめてそうな中年サラリーマンが異世界転生系もあるのでどうとでもできますが
あ、いかん「昼寝必須の中年サラリーマン」が別の意味でありえん。
Re: (スコア:0)
その辺の主人公ならソシャゲで鍛えられた絶対時感を持ってい(る設定があっ)てもおかしくない！
# 腕時計の電池はアホみたいにもつんじゃなかろうか
Re: (スコア:0)
電池駆動式の腕時計って、アナログでも年単位、デジタルだと(個体差はあるにしても)十年とか、結構持ちますよ。
Re: (スコア:0)
異世界でも物理定数は変わらないのかとか、そういった検証や設定まで突っ込み出したらキリがなんじゃないかな？
Re: (スコア:0)
物理定数を検証する云々て題名のラノベあったけど面白くなかった
結局魔法あるそうだけどどないだに走ってた
物理定数変わるくらいなら計測器なんて時計からして信用できんはずなんだが
そこは置いといて測れていた
まあ酸素足りない異世界と一緒で出オチのショートショートにしかならんだろうけど
Re: (スコア:0)
いろいろ有り物組み合わせて各種物理定数を検証してて
Re: (スコア:0)
理系が恋に落ちたので証明してみた。
Re: (スコア:0)
物理定数が変わったのと等価な気がする有名SFを知ってるけど、あれは異世界に意識的に行ってるから転移系ではないな・・・
＃れっつごー 中性子星！ いざゆかん、チーラの住む星へ！
Re: (スコア:0)
どうやって気づくんでしょう。（*12時間以外の微妙な時間でも可）
そこまで極端だと普通は何かおかしいと思うわけだが、それに気付かない主人公の超適応能力とか？
電波式腕時計・NTP時間設定型端末・GPS時間設定型端末では成り立たないですし、
むしろ神懸かりなデンパを受信して云々とか？
電池式駆動端末（スマホ・腕時計を含む）だと気づく前に停止しそうですし。
魔力駆動式になってて（よくある）、アプリ開発して魔道具化して（たまにある）
・機械式腕時計をは
Re: (スコア:0)
マンガでは20年ぐらい前に描かれた、なかざき冬のIN23H なんてのがありますね
Re: (スコア:0)
たくさんあるけど、
秒から分程度
実影響がない。なので描写がない/意味がない。
1時間以上
影響というか、「xxxを考慮してyyy」の描写はする、たまに必要な時間までの日数の差で「間にあわないから大変だ!」な話になったりする
くらいだね
TAIに統一したい (スコア:0)
失われた情報は復元できないのだから
内部表現ではうるう秒の存在を無視しないでほしい。
それを踏まえてうるう秒の挿入として処理するかleap smearingとして処理するかは
より上位の層が考えればよい話。
そもそも時刻の正確度と時間の正確度のどちらが要求が高いかといえば
ほとんどのアプリケーションで後者だと思う。
時刻の表示が1分ずれたところで何が困るというのか。
Re: (スコア:0)
ネットワーク関係では5秒以上の遅延が問題となる場合も多いが？
Re:TAIに統一したい (スコア:2)
地球上で共通なだけじゃ、すぐ古くなりそうだな。
今からTDBにしとけばいいのに。
the.ACount