
Windows 10 Insider Preview、うるう秒のテストが可能に 25
まだまだ消えないうるう秒 部門より
先日提供が始まったWindows 10 Insider Preview ビルド17723(RS5)/18204(19H1)では、w32tmコマンドに「/leapseconds」オプションが追加され、うるう秒のテストを実行できるようになっている。MicrosoftはWindows 10/Server 2019でのうるう秒サポートを7月18日に発表しているが、発表時のInsider Previewビルドでは「/leapseconds」が使用できなかった(ITプロフェッショナル向けテスト手順、開発者向けテスト手順)。
テストの手順を記載したITプロフェッショナル向けのドキュメント(docxファイル)はGitHubで公開されている。簡単なテスト手順としては、タスクバーの時計が秒を表示するようにレジストリを設定し、w32tmコマンドでうるう秒の挿入日時をセットすればいい。ドキュメントにはファイルのタイムスタンプ表示で秒を表示するよう設定する手順も記載されているが、日本語環境ではデフォルトで秒まで表示されるので設定は必要ない。
タスクバーの時計に秒を表示するには、レジストリの「HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced」にDWORD値「ShowSecondsInSystemClock」を追加し、値のデータに「1」をセットする。あとはWindowsを再起動すれば秒が表示されるようになる。
テスト用のうるう秒を設定するには、「w32tm /leapseconds /add:+年-月-日T時:分:秒/force /testmode」のようなコマンドラインを管理者権限で実行する。負のうるう秒を設定する場合、年の前にある「+」を「-」に置き換えればいい。日時の指定はUTCなので注意が必要だ。
通常、うるう秒はUTC 0時の1秒前に挿入されるが、w32tmコマンドでは任意の正時の1秒前に設定できる。一方、挿入タイミングは正時の1秒前に固定されるため、分:秒の部分は何を指定してもセットされるのは「59:59」になる。なお、再起動後まで設定が反映しない場合と、すぐに反映する場合があった。
あとは指定した時刻になるのを待つか、コンピューターの時刻を変更すればうるう秒を確認できる。たとえば日本時間の8時59分59秒に正のうるう秒を設定した場合、タスクバーの時計は8:59:59→8:59:60→9:00:00となる。ただし、タスクバーの時計をクリックすると表示されるカレンダーの時計や、「日付と時刻」コントロールパネルの時計は60秒が表示されず、59秒が2秒間表示され続ける。負のうるう秒を指定した場合は8:59:58→9:00:00となる。
テスト用うるう秒の解除方法は説明されていないが、上述のコマンドラインで「add」を「remove」に置き換えれば解除できた。テスト用うるう秒を解除すると、8時59分60秒に保存したファイルのタイムスタンプは9時0分0秒と表示されるようになる。なお、過去のうるう秒は特に設定されていないようだ。
狂わない時計も欲しい (スコア:0)
マザーボード上のRTC精度なんてたかが知れているから
原子時計も安くなったことだし、USBドングルみたいな形で、と思ったが
電源の問題があるか。
# NTP使えないところでは需要あるかも
Re: (スコア:0)
マザーボード上のRTCは、パソコンのシャットダウン中およびスリープ中に時刻を維持するために使われているだけです。
OSの稼働中は、OSがスケジューラーが、タイマ割込みとCPUのTSCとを連携させて、時刻を掲示している。
割込み禁止されたり、SMIが発生したりすると、当然OSによる経時の誤差が大きくなるので、NTPによる同期が必要になってきます。
Re: (スコア:0)
でもさー、重い処理をするとCPUが遅くなる事とかザラにあるけど
それでも時計が狂わないのってなんでなんだろう。
マウスカーソルがちょっと引っかかっる度に、その分遅くなりそう。
それとも、OSの見た目では処理落ちしているけど
CPUのクロック周波数的には常に一定のクロックを刻んでいるのかな
Re: (スコア:0)
省電力機能でSMIを発行されてCPUのクロックは常に変化している。だから、定期割込みのタイマ割込みのたびに、一周期にTSCでいくつカウントされたかを常にチェックして、微妙に調整しているのだ。そのため、省電力機能に不具合があったりすると、計時が出鱈目になる。
# Linuxのスケジューラーをいじっているときに計算式を間違えて、64倍速で時刻が進んでしまうカーネルを作ったことがある。
# 割禁デバイスドライバには滅んでもらいたい。
Re:狂わない時計も欲しい (スコア:1)
# 省電力と称してタイマまで止めくさるSoCは滅びよまったく
Re: (スコア:0)
マザーボード上のRTCはただのバックアップ用です。稼働中は、OSが時刻をカウントしてます。
Re: (スコア:0)
Windowsなら15msのタイマー割り込みを受けて、内部の時刻をカウントアップをしているわけでしょ。
そのタイマ割り込みの出元はRTC やったりするんやないの?
Re: (スコア:0)
今時はHPETやTSCじゃないのかな。
ACPIも歴史あるし、今時RTCとか使うのかな?
おまけ
https://www.valinux.co.jp/technologylibrary/document/linuxkernel/timer0003/ [valinux.co.jp]
Re: (スコア:0)
IRQ8のRTCはバックアップ用です。実際起動時とシャットダウン時とスリープの前後にしかアクセスしてません。
IRQ0のシステムタイマーってのが15msのタイマー割り込みのソースです。
Re: (スコア:0)
GPSの時刻情報をだけを受信するモジュールとか作れないかな
時刻情報なら衛星1つだけでもいいはずだし。大気の誤差とかまあいいでしょう
電波時計って時刻が確定するのに1分受信し続ける必要があってつらいけど
GPS電波なら1パケット(?)受信するだけで時刻確定したりしないかな
Re: (スコア:0)
電源の問題がないなら凄く簡単に作れるよ。
1秒毎に送られてくるから秒単位でなら凄く簡単に時間を合わせられる。
ただ鉄筋コンクリートのビルの中だと厳しいかも。
GPS時計&NTPサーバなんてのを自作してる人もいるね。
ネットのない環境で正確に時間を合わせたい場合に使えそう。
Re: (スコア:0)
測位が終わらんと時刻も決まらん
大気の誤差より衛星までの距離分の誤差になるからもう少し大きい
高度約二万キロなんでミリ秒単位はある
♯真上にあるやつのみをつかめるわけじゃないので事前補正は無理だろう
作れなくはないけど測位モジュールができている以上誰が
こんだけ誤差がある計時のみを作るかって話
Re: (スコア:0)
適当なこと言うなよ。測位しなくてもUTC時刻は出るぞ。一個掴めば秒単位の時刻が出る。4個掴めば地方時が出る。置いておけばマイクロ秒単位に収束する。
次にお前は「1PPS信号の精度は1秒」と言いそうなので言っておくが、そんなこともないからな。
Re: (スコア:0)
> 適当なこと言うなよ。測位しなくてもUTC時刻は出るぞ。
間違ってますよ。それはUTC時刻ではありません。
正しい時刻を求めるには
受信した時刻から、衛星までの距離に応じた電波の遅延分を時刻に加算する必要があります
言い換えると
あなたは数ミリ秒遅れた時刻(しかもその遅れが何秒かさえ解ってない)を
UTC時刻と勘違いしているだけです
Re: (スコア:0)
GPS を使った NTP サーバは数万円で簡単に手に入るよ。
RTC だけの精度が原子時計レベルになったらレベルでも暗号とかあっちの方面では嬉しいのかな。
スマホが原子時計を内蔵できるくらいになったら色々凄いことになると思うけど。
うるう秒とは? (スコア:0)
これを導入することでうるう年が無くなるということ?
Re: (スコア:0)
別物
時刻をそのまま使い続けるために閏秒はある
閏秒があるからといって閏年はなくならん
実は用語としての使い方もずれてる
閏秒とか閏月はそいつを挿入することでずれを補正する
♯閏三月とか三月とは別に設けられ通常の月より短かったりする
閏年ってのは閏日のある年のこと
変則的な閏年を挿入するわけじゃない
現在の暦法では閏日は2月29日で固定
こいつの挿入方法を4000年の範囲で暦と季節のが大きくならずに
すむよう規定してある
一年(恒星年と太陽年の違いは置いといて)が一日(一太陽日)の
整数倍じゃないことを吸収
閏秒ってのは微妙なずれを補正していて、観測結果から適宜挿入する
自転、公転が揺らぎながらだんだん遅くなってるのを補正してる
Re: (スコア:0)
地球の公転周期が365.2422日ぐらいで、いまのうるう年の挿入パターンだと
1年は365.2425日でしたっけ
Re: (スコア:0)
・ 365 < 365.24218944 なので、 |365-365.24218944| 以上となり、分母が 1 の倍数になる 1÷4 で加算する (365.25 日)
・ 365.24218944 < 365.25 なので、 |365.24218944-365.25| 以上となり、分母が 4 の倍数になる 1÷100 で減算する(365.24 日)
・ 365.24 < 365.24218944 なので、 |365.24-365.24218944| 以上となり、分母が 100 の倍数になる 1÷400 で加算する (365.2425 日)
という後付けの式でグレゴリオ暦法をなぞってみる。
この調子だと
・ 365
今後の仕様 (スコア:0)
NTPが閏秒フラグを立てていたら、自動で閏秒挿入をするようになるのかな?
シリアル値の仕様は? (スコア:0)
最後にファイルのタイムスタンプの話が出てたけど、そういうシリアル値で保存している場合の仕様って基本どうなってるの?
・うるう秒込みのカウントになり、毎分0秒が60の倍数でなくなる
・うるう秒を含まない値だが、別途うるう秒であることを示すフラグがある
・60秒は59秒としてきろくされ、うるう秒はなかったことにされる。
NTFSは最後のではないみたいだけど、どんな仕様になったのかな?
てか、主流派はどんなの?
Re: (スコア:0)
うるう秒で作ったファイルを、ntfs経由 もしくはsamba経由、もしくはzip 7zip圧縮したらどうなるのかも知りたいな
Re: (スコア:0)
シリアル値は特定時刻からの経過秒数とか経過100ナノ秒数で定義されているから当然うるう秒込みでしょ(つまり一番目)。したがって過去のうるう秒がすべてわかっていないと日付とシリアル値の変換はできない。NTFSの場合、互換性のためにうるう秒機能導入以前のうるう秒はすべてなかったことにする気もするけど
Re: (スコア:0)
互換性のためにうるう秒機能導入以前のうるう秒はすべてなかったことにする気もするけど
自分もそこが気になるけど、OSでうるう秒を任意に定義できる方式だと無理な気がする。
あくまで主はシリアル値で、解釈表示される時刻は仮のものという発想の転換が要るのかもしれない。
…と理屈ではなるけど、日付変わるのはインパクトあるな。
Re: (スコア:0)
FATに奇数秒ができたりとヤバいな