アカウント名:
パスワード:
ここ [science.srad.jp]でコメントされたように、> Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)> Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる> Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)の選択で議論されたようですが、 プレスリリース [itu.int]によると、とりあえず現状維持で2023年にもう一度決めます、というように読めます。
物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
理想的には、「世界協定1秒とは地球から見て太陽が360/(24×60×60)度分、移動するのにかかる時間である」と時々刻々と変化するよう定められれば綺麗だけど。それは無理があるので、例えば、毎年1月1日に、次の12月31日に「自転的な1日の終わり」と「暦上での1日の終わり」が同期するよう狙いを付けて更新する(実際に次の12月31日の終わりには、ずれちゃうだろうけど、その誤差は蓄積しない仕組みなので気にしない)、とかそういうルールを決めて。
「 うるう秒がやって来る！〜 6 月 30 日 [blogspot.jp]
> 物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
だから，時々うるう秒を入れてきた訳で，それが楽だから当面存続することにした，ってニュースなんですが...
でも、うるう秒を一発で入れないやり方をGoogleみたいな大規模なシステム運用者が取ってるんですよ。多分、そっちの戦略のが楽なんですって。
楽って言われると、ずるっぽくも聞こえますが、「60秒」という表現が存在しないシステムでは、本当に唯一無二のやり方なのでは？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
先延ばし (スコア:0)
ここ [science.srad.jp]でコメントされたように、
> Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)
> Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる
> Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)
の選択で議論されたようですが、
プレスリリース [itu.int]によると、とりあえず現状維持で2023年にもう一度決めます、
というように読めます。
Re: (スコア:0)
物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
理想的には、「世界協定1秒とは地球から見て太陽が360/(24×60×60)度分、移動するのにかかる時間である」と
時々刻々と変化するよう定められれば綺麗だけど。
それは無理があるので、例えば、毎年1月1日に、次の12月31日に「自転的な1日の終わり」と「暦上での1日の終わり」が
同期するよう狙いを付けて更新する(実際に次の12月31日の終わりには、ずれちゃうだろうけど、
その誤差は蓄積しない仕組みなので気にしない)、とかそういうルールを決めて。
「 うるう秒がやって来る！〜 6 月 30 日 [blogspot.jp]
Re: (スコア:0)
> 物理単位としての秒は固定のまま、時々変わる、世界協定秒を定めた方が楽だと思う。
だから，時々うるう秒を入れてきた訳で，それが楽だから当面存続することにした，ってニュースなんですが...
Re:先延ばし (スコア:0)
でも、うるう秒を一発で入れないやり方をGoogleみたいな大規模なシステム運用者が取ってるんですよ。多分、そっちの戦略のが楽なんですって。
Re: (スコア:0)
楽って言われると、ずるっぽくも聞こえますが、「60秒」という表現が
存在しないシステムでは、本当に唯一無二のやり方なのでは？