うるう秒の当面の存続が決定 53
ストーリー by hylom
次はいつだっけ 部門より
次はいつだっけ 部門より
国際電気通信連合（ITU）の世界無線通信会議が、当面はうるう秒を存続させるという決定を行った（日経新聞）。
「さらに研究を進める必要がある」ということで廃止を見送ることになったようだ。ただし廃止の可能性がなくなったというわけではなく、2023年の会議で再度研究結果を検討するという。
国際電気通信連合（ITU）の世界無線通信会議が、当面はうるう秒を存続させるという決定を行った（日経新聞）。
「さらに研究を進める必要がある」ということで廃止を見送ることになったようだ。ただし廃止の可能性がなくなったというわけではなく、2023年の会議で再度研究結果を検討するという。
犯人はmoriwaka -- Anonymous Coward
やめてくれー (スコア:1)
うるう病対応はもういやだ。
うるう秒の度にどっかのシステムがちょこちょこ問題起こすんだよなぁ。
サービス再起動やら、システムリブートやらで何とかなるけどさ。
不定期に一秒増減させるのに何の意味があるんだか。
10秒程度ズレがたまってから一気にずらせよ・・・
Re: (スコア:0)
どんなシステムがどんな原因で問題起こしているか分からないけど、うるう秒の度に問題起こすくらいのシステムなら10秒もズレたら大問題にならない？
Re: (スコア:0)
変にうるう秒対応するから2度同じ時間をさまよってトラブるが起きるのでサーバーが勝手に時間がずれても問題にはならない。そして1秒でも10秒でも変わらない。
Re: (スコア:0)
その変な対応を直せよ。
Re: (スコア:0)
その変な対応を直せよ。
前々回は発生したけど、
今回は発生してないだろ？
Re: (スコア:0)
ですから１秒という長い時間ずれがたまってから一気にずらしているわけですが。
嫌ならシステムを２秒単位とか１０秒単位、いっそのこと分単位で認識記録してはいかがです？
Re: (スコア:0)
いっそのこと、うるうピコ秒を導入してはどうでしょうか？
これならたいていのシステムは時間のずれに気がつかないはず。
Re: (スコア:0)
FAT「呼んだ?」ZIP「お前じゃねーよ」
Re: (スコア:0)
サーバーリプレイスのときに対応すればいいのでは。
常に同じハードウェアが動き続けるわけではないんじゃないの？
そういえば本当にノンストップのシステムの場合、リプレイスの場合はどうするんだろう。
Re: (スコア:0)
その場合多重化されてるはずだから（はず・・・）
片肺運用にして交換するんじゃないかな。
通信事業者系のシステムは建前ノンストップだから
システム全体リプレースする場合もそりゃ大騒ぎよ
Re: (スコア:0)
ずらす頻度が減って一回あたりのずらす量が増えたらかえってトラブルが増えると思いますが。
Re: (スコア:0)
ずらす量を1秒以下というか時刻配信システムの精度以下にしてもらえば大半のシステムは特に対処しなくても補正されるんだろうけどねぇ…
Googleは20時間かけてずらしたとか言うけど、そういうのをデフォにして厳密な機器以外無視出来るってのが理想。
協定世界時 (スコア:0)
一日が86401秒になるのは、何世紀先なんだろう。
その前に、毎年→毎月→毎週うるう秒が付く様になってからだろうが、マスドライバー等で、地球自転方向に大量・大質量投射が行われる様になってからは、意外と早いかも。
但し同時に地球公転方向へのマスドライバー等での大量・大質量投射が行われるだろうから、一年＝地球公転周期が短くなって、一年に対しマイナスうるう秒が定期的に付く様になる方が早いかも。
Re:協定世界時 (スコア:1)
太陽・地球の質量変化に伴う変動分その他にも対応して、公転・自転周期を一定に保つ＆暦を設定しやすいような周期に調整するってのは、ありかもしれませんなぁ。
そのために必要なエネルギーがお気軽に入手できるとは思いませんが。
Re: (スコア:0)
うるう秒はピザ体系の人が増えたせいで地球の質量が増えてしまったからだったんだよ！
な、なんだってー！ΩΩΩ
Re: (スコア:0)
調整イヤなら、月日時分という単位を捨てて、1/1 0:0:0からの経過秒のみ使おう。
ほらスッキリするw
Re:協定世界時 (スコア:2)
> 月日時分という単位を捨てて、1/1 0:0:0からの経過秒のみ使おう。
その場合、経過秒が何秒で次の年になるのでしょうか。
基本31,536,000秒(=365×24×60×60)で、4年に一回31,622,400秒(366×24×60×60)になって、
たまに31,536,001秒(=365×24×60×60)になったりするんですよね。
何の解決もしてなさそうです。
31,556,952秒(=(365×303+366×97)×24×60×60÷100、グレゴリオ歴400年の秒数の年平均)で繰り上がるようにすれば、閏年は考えなくてすむけど、
うるう秒は地球の自転に基づいて入れるから事前計算は不可能で、たまに31,556,953秒な年を入れないとだめっすね。
Re: (スコア:0)
100年に一度のうるう年ではない100で割り切れる年
400年に一度のうるう年
が入ってないよ
なので、この計算はやらないほうがマシ
Re:協定世界時 (スコア:1)
> 100年に一度のうるう年ではない100で割り切れる年
> 400年に一度のうるう年
> が入ってないよ
入れてますよ。
(元コメでは÷400と書くところを÷100と書いてしまってましたが)
400年単位で考えると、ユリウス歴なら閏年は100回ありますが、
グレゴリオ歴では閏年が3回減って閏年は97回になりますので、
> 31,556,952秒(=(365×303+366×97)×24×60×60÷
100という計算式になります。
Re:協定世界時 (スコア:1)
しまった、ミスの訂正をミスってる。
> 31,556,952秒(=(365×303+366×97)×24×60×60÷
100これは、正しくは
> 31,556,952秒(=(365×303+366×97)×24×60×60÷400
です。
#グレゴリオ歴では平均して一年は365.2425日、というのを覚えておけば、
# 365.2425*86400で簡単に求まりますけどね。
Re:協定世界時 (スコア:2)
一年は365.2425日
そこまで踏み込むなら365.2422 (太陽) 日を使った方がすっきりすると思うわたしは少数派。
Re:協定世界時 (スコア:1)
> 365.2422 (太陽) 日を使った方がすっきりする
言われてみればその通りですね。思い浮かばなかった自分が恨めしい…
オフトピ(-1) (スコア:1)
＞恨めしい…
天狗の仕業ぢや
ということにすればなにものかに恨みや敵愾心を向けないで済ませられますよ。
お試しあれ。
Re: (スコア:0)
天狗さん涙目
Re: (スコア:0)
なんで時分秒は0から始めて月日は1から始まるんですか？
Re: (スコア:0)
テストの点は０から始めて通信簿は１から始めるようなものですか？
Re: (スコア:0)
月はJanuaryから始まって配列がゼロベースのC言語では先頭要素が無駄になるからstruct tmでは月はゼロから始まります。
Re: (スコア:0)
マスドライバーで1日の長さを調整すれば良いじゃない。
Re: (スコア:0)
何世紀も先になれば、うるう秒の扱いができないような旧式のシステムはなくなっていると思います。
Re: (スコア:0)
何世紀経とうが質の悪いシステムが根絶されることはないと思う。
Re: (スコア:0)
どちらにせよ、そんな出来の悪い子のためにマスドライバーを持ち出すのは、甘やかしすぎでしょうね。
Re: (スコア:0)
年を2桁にしたプログラマー「せやな」
Re: (スコア:0)
そんな時代になったら地球外に住む人も増えて
なんで地球の自転に合わせて時計をいじらにゃならんのだって話に……
2023 年までは (スコア:0)
ほんのちょっとだけ長生きできる、良かった
Re: (スコア:0)
むしろ、寿命を年で数えるとわずかに小さくカウントされるのでは？
マイナスの閏秒が挿入される可能性もなくはないですが。
先延ばし (スコア: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)
これから自転が遅くなり一日が長くなるので
2000年頃以降はそれ以前より速くなっているようですよ。なのでうるう秒の挿入もまばらに。 [wikimedia.org]
libcの実装が面倒くさい (スコア:0)
しかもメンテを続けるか定義を外部ファイル化でもしないといけないという
Re: (スコア:0)
たまにしか無いからなかなかバグがなくならないのであって、毎日どっちかに（無理やり誤差を与えて）うるう秒を入れることをやってたら1〜2ヵ月でバグが取れたntpdに切り替わるんでなかろうか。そうしたら後は人手が掛かるところは大元の協定時を決める人が数人だけに絞られ、末端の私たちは気にしなくていい世界になるんじゃないかな。NTPに同期しないところはそもそも厳密に協定時に合わせる必要はないだろうし。
Re: (スコア:0)
夏時間の定義は国や地域によって違うし変更されることもよくあって、
実際、夏時間定義にからむアップデートはしょっちゅうあります。
それと同じようなものだと思えばたいしたことないのでは。