アカウント名:
パスワード:
ここ [science.srad.jp]でコメントされたように、> Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)> Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる> Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)の選択で議論されたようですが、プレスリリース [itu.int]によると、とりあえず現状維持で2023年にもう一度決めます、というように読めます。
個人的には、これから自転が遅くなり一日が長くなるので日常生活に密接したUTCについてはうるう秒を維持つつ、システムとして(例えばOSが)管理するのは国際原子時のみにして表示の時にUTCなり現地時刻なりに変換するような仕組みを導入するのが想定外の事故を起こさないためにも妥当なところと思います。
物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
理想的には、「世界協定1秒とは地球から見て太陽が360/(24×60×60)度分、移動するのにかかる時間である」と時々刻々と変化するよう定められれば綺麗だけど。それは無理があるので、例えば、毎年1月1日に、次の12月31日に「自転的な1日の終わり」と「暦上での1日の終わり」が同期するよう狙いを付けて更新する(実際に次の12月31日の終わりには、ずれちゃうだろうけど、その誤差は蓄積しない仕組みなので気にしない)、とかそういうルールを決めて。
「 うるう秒がやって来る!〜 6 月 30 日 [blogspot.jp]
>世界協定秒それって1971年までのUTCでやってた周波数オフセットのことだよ。それが面倒になったから不連続なうるう秒にしたのさ。
> 物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
だから,時々うるう秒を入れてきた訳で,それが楽だから当面存続することにした,ってニュースなんですが...
元コメの主張は、現状のような「国際原子時も、協定世界時も、1秒の単位は同じのままで、世界協定時では離散的に1日の秒数が1秒増える」ような実装ではなく、「1 協定世界時秒 = 1.00000000906 国際原子時秒」などと定義し、協定世界時はうるう秒なしの「1日=86400協定世界時秒」固定で運用する、という話でしょう。
で、地球の自転速度の変動に対しては、「2015年7月1日より、1協定世界時秒 = 1.00000001057 国際原子時秒に変更します」というように、協定世界時秒の定義そのものが「時々変わる」ような対応を行う、というのが#2921033 [science.srad.jp]の主張だと思います。
1世界協定時秒の定義がころころと変わられると、自前でまともに計時するのは不可能に近くなるでしょうけど、まあ、NTPなどで時刻を配るのが前提で、自前の計時を捨てられるなら、そういう運用もありかもと思いますね。
全世界的にやるのが難しかったら、各々が勝手にそういう運用するという手もあるな。
単にntpdに「うるう秒を無視する」というオプションを用意して(あるいは、すでにあったりするのかな?)、各組織内のトップのNTPサーバでそれをONにして、組織内の機械は全部それを参照させるだけ。すると、そのNTPサーバは、うるう秒が挿入された瞬間、「なぜか1秒ずれた」と見なして、通常の動作通り、長い時間をかけてその1秒に追いつくように調整するはず。
他のツリーにあるように、うるう秒対応が辛い、というならそういう設定にしちゃえば良いだけのような…。「そんな事が社会的に許されるのか」というツッコミに対しては、「Googleさんですらやってるのに?」で押し通す。
でも、うるう秒を一発で入れないやり方をGoogleみたいな大規模なシステム運用者が取ってるんですよ。多分、そっちの戦略のが楽なんですって。
楽って言われると、ずるっぽくも聞こえますが、「60秒」という表現が存在しないシステムでは、本当に唯一無二のやり方なのでは?
1秒の定義更新を受信できないシステムで常時1秒が狂うくらいなら、うるう秒ないしうるう秒時間(ntpみたく、ゆっくりずらして補正する期間)を設けて一定期間中だけエラーが出るシステムのほうがありがたいわ。時計用水晶振動子を毎年作り変えるとか悪夢だろう。秒の定義の違いによる問題も出てくるだろうしろくなことがない。
時計用水晶振動子って、年差1秒未満みたいな高精度になりうるの?年単位で外部からの補正が不要な時計がそれほど使われてるとはちょっと信じがたい。
そんな精度は出ないにしてもなんらかの「1秒」を基準に作る事になる。そうなるとたとえ大差なくても「型番XXXYYYはYYY年の1秒が基準で、型番XXXZZZはZZZ年の…」と作り分ける要求がどっかから出てきてもおかしくないし、どこかは作る、非常に鬱陶しい。
クロックをカウントする値を変えればいいだけでは?水晶振動子って1Hzだと思ってた?
32.768kHzとかがデフォですが、これで1も変えたら変え過ぎ。そもそも折角2^nに合わせてるのにプラマイしたら台無しだよ。時計用クオーツのデファクトを一新する勢いでシステム変えるとかも無理があるし。
これから自転が遅くなり一日が長くなるので
2000年頃以降はそれ以前より速くなっているようですよ。なのでうるう秒の挿入もまばらに。 [wikimedia.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
先延ばし (スコア:0)
ここ [science.srad.jp]でコメントされたように、
> Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)
> Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる
> Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)
の選択で議論されたようですが、
プレスリリース [itu.int]によると、とりあえず現状維持で2023年にもう一度決めます、
というように読めます。
個人的には、これから自転が遅くなり一日が長くなるので日常生活に密接したUTCについてはうるう秒を維持つつ、
システムとして(例えばOSが)管理するのは国際原子時のみにして表示の時にUTCなり現地時刻なりに変換するような仕組みを導入するのが
想定外の事故を起こさないためにも妥当なところと思います。
Re: (スコア:0)
物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
理想的には、「世界協定1秒とは地球から見て太陽が360/(24×60×60)度分、移動するのにかかる時間である」と
時々刻々と変化するよう定められれば綺麗だけど。
それは無理があるので、例えば、毎年1月1日に、次の12月31日に「自転的な1日の終わり」と「暦上での1日の終わり」が
同期するよう狙いを付けて更新する(実際に次の12月31日の終わりには、ずれちゃうだろうけど、
その誤差は蓄積しない仕組みなので気にしない)、とかそういうルールを決めて。
「 うるう秒がやって来る!〜 6 月 30 日 [blogspot.jp]
Re:先延ばし (スコア:1)
>世界協定秒
それって1971年までのUTCでやってた周波数オフセットのことだよ。
それが面倒になったから不連続なうるう秒にしたのさ。
the.ACount
Re: (スコア:0)
> 物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
だから,時々うるう秒を入れてきた訳で,それが楽だから当面存続することにした,ってニュースなんですが...
Re:先延ばし (スコア:1)
元コメの主張は、現状のような「国際原子時も、協定世界時も、1秒の単位は同じのままで、世界協定時では離散的に1日の秒数が1秒増える」ような実装ではなく、
「1 協定世界時秒 = 1.00000000906 国際原子時秒」などと定義し、協定世界時はうるう秒なしの「1日=86400協定世界時秒」固定で運用する、という話でしょう。
で、地球の自転速度の変動に対しては、「2015年7月1日より、1協定世界時秒 = 1.00000001057 国際原子時秒に変更します」というように、協定世界時秒の定義そのものが「時々変わる」ような対応を行う、というのが#2921033 [science.srad.jp]の主張だと思います。
1世界協定時秒の定義がころころと変わられると、自前でまともに計時するのは不可能に近くなるでしょうけど、
まあ、NTPなどで時刻を配るのが前提で、自前の計時を捨てられるなら、そういう運用もありかもと思いますね。
Re: (スコア:0)
全世界的にやるのが難しかったら、各々が勝手にそういう運用するという手もあるな。
単にntpdに「うるう秒を無視する」というオプションを用意して(あるいは、すでにあったりするのかな?)、
各組織内のトップのNTPサーバでそれをONにして、組織内の機械は全部それを参照させるだけ。
すると、そのNTPサーバは、うるう秒が挿入された瞬間、「なぜか1秒ずれた」と見なして、
通常の動作通り、長い時間をかけてその1秒に追いつくように調整するはず。
他のツリーにあるように、うるう秒対応が辛い、というならそういう設定にしちゃえば良いだけのような…。
「そんな事が社会的に許されるのか」というツッコミに対しては、「Googleさんですらやってるのに?」で押し通す。
Re: (スコア:0)
でも、うるう秒を一発で入れないやり方をGoogleみたいな大規模なシステム運用者が取ってるんですよ。多分、そっちの戦略のが楽なんですって。
Re: (スコア:0)
楽って言われると、ずるっぽくも聞こえますが、「60秒」という表現が
存在しないシステムでは、本当に唯一無二のやり方なのでは?
Re: (スコア:0)
1秒の定義更新を受信できないシステムで常時1秒が狂うくらいなら、
うるう秒ないしうるう秒時間(ntpみたく、ゆっくりずらして補正する期間)
を設けて一定期間中だけエラーが出るシステムのほうがありがたいわ。
時計用水晶振動子を毎年作り変えるとか悪夢だろう。
秒の定義の違いによる問題も出てくるだろうしろくなことがない。
Re: (スコア:0)
時計用水晶振動子って、年差1秒未満みたいな高精度になりうるの?
年単位で外部からの補正が不要な時計がそれほど使われてるとはちょっと信じがたい。
Re: (スコア:0)
そんな精度は出ないにしてもなんらかの「1秒」を基準に作る事になる。
そうなるとたとえ大差なくても「型番XXXYYYはYYY年の1秒が基準で、型番XXXZZZはZZZ年の…」
と作り分ける要求がどっかから出てきてもおかしくないし、どこかは作る、非常に鬱陶しい。
Re: (スコア:0)
クロックをカウントする値を変えればいいだけでは?
水晶振動子って1Hzだと思ってた?
Re: (スコア:0)
32.768kHzとかがデフォですが、これで1も変えたら変え過ぎ。
そもそも折角2^nに合わせてるのにプラマイしたら台無しだよ。
時計用クオーツのデファクトを一新する勢いでシステム変えるとかも無理があるし。
Re: (スコア:0)
これから自転が遅くなり一日が長くなるので
2000年頃以降はそれ以前より速くなっているようですよ。なのでうるう秒の挿入もまばらに。 [wikimedia.org]