「うるう秒」廃止へ ? ITU が新方式を検討中 84
ストーリー by reo
4 年経過して足踏み ? 部門より
4 年経過して足踏み ? 部門より
ある Anonymous Coward 曰く、
国際電気通信連合 (ITU) は UTC (協定世界時) から「うるう秒」を廃止することを検討しているそうだ (PC World の記事、本家 /. 記事より) 。
1971 年から導入されている「うるう秒」は、ソフトウェアが不具合を起こす一因となっている。2008 年末のうるう秒調整においてはオラクルのソフトウェアが予期せずリブートするといったバグが発生していた。
ITU では、UTC (協定世界時) とUT (世界時) との差を今後数百年に渡り修正せず、ある時点で「うるう時間」として一気に修正を行うという新たな方法が検討されているとのことだ。
問題の先送り (スコア:5, すばらしい洞察)
問題の先送りをしているだけというように思うのは私だけだろうか？
屍体メモ [windy.cx]
Re:問題の先送り (スコア:5, おもしろおかしい)
Re: (スコア:0)
Re:問題の先送り (スコア:2, すばらしい洞察)
>問題の先送りをしているだけというように思うのは私だけだろうか？
問題を先取りすれば？
簡単に廃止したり、復活したり出来るのなら、
１０分進めておくと、当分大丈夫。
Re:問題の先送り (スコア:1)
細切れに繰り返し、その都度トラブルが発生するよりは100年くらいの単位で補正する事にしておけばトラブル回数は減るし、対応のための準備も（2000年問題みたいに）大々的に出来るってことじゃない？
１番のメリットは、自分たちがもう閏秒にまつわるトラブルに見舞われることがなくなるってことで・・・・
Re:問題の先送り (スコア:2, 興味深い)
うるう秒だったらソフトウエアで自動修正させなきゃならんが、
ううう時間だったら、手動で再起動かけてもいいんじゃね？
Re:問題の先送り (スコア:1, おもしろおかしい)
Re:問題の先送り (スコア:1)
>細切れに繰り返し、その都度トラブルが発生するよりは100年くらいの単位で補正する事にしておけばトラブル回数は減るし、対応のための準備も（2000年問題みたいに）大々的に出来るってことじゃない？
どうなんだろう？
何回もトラブルを含めて経験して、それに対応できる様にしていくってのもありだと思う。
後で一気にやって、そこでトラブルが出ると、必然的に大きなのになりそう。
# 夏休みの宿題を思い出すね
>１番のメリットは、自分たちがもう閏秒にまつわるトラブルに見舞われることがなくなるってことで・・・・
後世に禍根を残さない様に、うちらがいまのうち苦労しようよ..というのは、廃れた美風なのかもしれないな。
とかいいながら、後世に残している借金やら環境とかね。
Re:問題の先送り (スコア:1)
やっぱり技術の伝承は必要ですね
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:問題の先送り (スコア:1)
うるう年の扱いでも問題が出てましたよね？
じゃあ、いっそのこと……
-- う～ん、バッドノウハウ？
Re: (スコア:0)
寿命の無いあなたにとっては深刻な問題かもしれませんが、
我々人間にとっては、何百年後に問題が起ころうが知ったことではありません。
＃これをネタにして、うるう秒修正に関する検討報告書をサボろうと思うのでAC
Re: (スコア:0)
Re: (スコア:0)
結局，従来どうり閏ナントカにするしかなくって，その実施頻度が多いか少ないかだけでソフト側の対応処理のバグを根絶することは望み薄でしょう
ずっと閏秒を続ければ既存のソフトのバグは徐々に減るはずだが（バグが発覚したら修正するから），新規に開発したソフトの閏秒対応処理に一定の割合でバグが入り込むので，トータルするとトラブルはなかなか減らないのか（トホホ
ぷぃにゅ～ (スコア:3, 参考になる)
永久に直さなくても (スコア:3, 興味深い)
どうせなら、永久に直さなくても、いいのでは。
何百年、何千年という時間で徐々に変わるのなら、6時が真夜中だろうが日付けが昼間に変わろうが、
そういうものだ、とうふうに生活習慣が変わるのでは。
Re:永久に直さなくても (スコア:1)
＞永久に直さなくても
同感！
過去を振り返ると、始めのうちUTCを細かく調整してたのが面倒になったか不必要だと分かったのか、1秒単位の調整になって今まで来たけど、秒単位調整も不要なら、もはやUTCなしで原子時をそのまま使えば良い。(原子時とUTCの差は今でも秒単位)
the.ACount
うるう「時間」 (スコア:2, 興味深い)
と命名している以上、現実の地球の進行と「時間」単位でズレてから修正されるってことですよね。今は良いけど、未来のどこかで無期限逆サマータイム的な、「明日から朝が一時間遅くなります」という時が訪れるんでしょうか。なんかそれはそれでいまいちな感じもしますが。
まぁ、確かに「地球の進行」みたいなふらついているものをベースにしているのが問題なんでしょうけれど、とはいえ「朝日が昇って夜日が落ちる」みたいなのからは、地球に住んでいる限りは縛られていそうです。なので根本的解決として、「宇宙進出」を提案したいところ。
Re: (スコア:0)
いう形で決着したりして(´・ω・`)
Re:うるう「時間」 (スコア:1, 参考になる)
別ACだけど、どこと聞かれても、ほとんど全部が嘘に見えるんだよね。
少なくともこれは大嘘。地球の公転もカレンダー（うるう年のアルゴリズム）も、うるう秒とは関係がない。
公転周期と自転周期（正確には平均太陽日）の間の調整をするのがうるう年、
自転周期と（SIで定義された）秒の間の調整をするのがうるう秒なので、二つの調整は独立なもの。
それから、うるう年のアルゴリズムを変えて、30日くらいまとめて13月を入れて調整したっていいわけで、
「アルゴリズムがそうなっているから1日単位しかありえない」というのは論理が逆。
それを言ったら、うるう秒も今は1秒単位で挿入する約束になってるわけで、1秒単位の調整しかありえない。
困る (スコア:2)
コンピュータの時計を実生活で使っている人が多い世の中では、かなり困る話だと思う
まあ、私は、いい加減な生活なので、1分程度だと構わないのですが、最終電車ぎりぎりとかの生活をしている人は困る世界だと。
Re:困る (スコア:1)
社会全体でズレていれば何ら問題ないかと思いますが、何か影響がでるのでしょうか? どう考えても何の問題も起きないと思いますが。
サマータイムで「今日から一時間変わります」であっても、社会全体でその時間にずらしていますし、物理法則を無視して「一時間電車が来ない」「一時間電車が早く到着した」などという事はないでしょう。
どうせたまーに NTP で合わせたら数秒単位でずれてましたとかいう機械だって大量にありますし、自然界における時の流れをどのように正確に表現しようかというコダワリ程度のものでしかない訳ですから、そんな事を気にする必要はありませんよ。
Re:困る (スコア:1)
>社会全体でズレていれば
その前提が....
全部で崩れていいなら、そもそもそんなものは必要ないでしょ？
Re:困る (スコア:1, 参考になる)
パソコン，サーバーの内蔵クロックや日常生活のレベルではそうですが，そうでない（一日の長さが地球の自転と同期して，なおかつ高安定度のクロックが必要な）システムも世の中に混在しているので面倒なことになってるわけです。
両者の関係をきちん対応させるに全世界的な統一ルールを作って一斉に閏秒を追加するのが最良で，一秒の長さを引き延ばして長い時間をかけて閏秒の処理をしたりすると，一秒の長さが変動しないことを前提としている計測システムなどでは非常に困ることになります。
ズレて問題の無いシステムとズレたら困るシステムを完全に切り離して別々に管理してしまえば良いかというと，どこかで両者が連接していることが多いので，極端なズレが生じないような処理が必要になるわけです。（GPSのクロックはズレ補正無しの独自の時刻系を使っているそうですが）
Re: (スコア:0)
テスト環境を作ろう (スコア:2)
SIの10進以外の最後の砦攻略 (スコア:2)
SI単位系の中で最後まで10進以外を使っている時間・角度を
10進化するいいチャンスなのでは？
Swatch Internet Time の不人気を見ると厳しいそうだけど。
賛成一票 (スコア:1)
１時間じゃなくて、１分溜まったら（これでも100年ぐらい掛かるんじゃない？）うるう分とかね。
テーブル用意するのが大変になる
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:賛成一票 (スコア:1)
一時間だと感覚的なズレも大きくなりそうなので、確かに一分程度が良いですね。
毎年一秒程度ずれても60年は修正の必要が無いし、今までの感じから大体1年半に一秒程度としても90年は大丈夫ですよね。
# 100年も経てば他の解決法とかなんか出来てそう。…それか時計自体必要の無い世界になってるかも。
Re:賛成一票 (スコア:5, すばらしい洞察)
伊勢神宮は20年に一度建て替えるから、宮大工の技術がきちんと継承されるらしい。
「90年に1度」にしてしまうと、「前回」の経験があるエンジニアが誰もいなくなるので、おそらく、その年がくれば2000年問題のように社会問題になる。
そんなことをするぐらいなら、むしろ、毎年リニューアルしたほうがいい。「毎年改定される」というのが社会通念になると、ソフトウェアはそういう方向に進化するだろうから、何の問題も無くなるはず。閏病が挟まれるたびに場当たり的に改定するのをやめて、もし1秒たりとも閏秒を挟まない年でも、「○月×日は『時計あわせの日』」を制定して、「やあ、今年の閏秒はゼロだったね」とかいう風にすればいい。
やがて (スコア:1)
Re: (スコア:0)
山手線何本分の誤差になるんだ！？
。。。次のに乗ればいいか。。。
1.01秒とかにすればいいんじゃね？ (スコア:1)
（#1815773でも言ってるけど）5分に一回、0.01秒を挿入する、…というのを100回繰り返すとかのほうがよくね？
上位のNTPサーバが対応すれば、一般の機器はNTPによる修正を受け入れればいいだけになるじゃん。
# この方法だとどういう所で困るんだろ
# mishimaは本田透先生を熱烈に応援しています
Re:1.01秒とかにすればいいんじゃね？ (スコア:2)
Re: (スコア:0)
同感。
そもそも、そういう細かい時間に依存してるシステムって、普段から実時間との誤差をどうやって修正してるんですかね？どうやっても絶対に誤差は出るはずだと思うんですけど。
NTPか何かで修正してるなら、うるう秒のずれもそれと同じ仕組みで修正すればいいだけだと思うんだけど…。
定義と実装と運用と (スコア:2, 参考になる)
ntpdは128ms以内であれば1/2000で操作します。閏秒も例外的にそうすればよいですが、その代わり2000秒間は定義上の時刻とずれることになります。後々定義上の時刻を知りたいときに、計算が面倒かもしれません。それでも1秒くらいずれていても気にしないという場合は、面倒な計算をしないということも含め、運用上はありです。ただ、実装としてそれしかないと困るかもしれません。kernel, date, ntpdなどが同じ方式で正しく実装していないと、正確な時刻が知りたい人は困ることになります。
逆に、59秒が2回になっても気にしない。その1秒以外は定義上の時刻とあっている、59秒を2回繰り返す方法をとる、という手もありです。計算も面倒じゃない。すべてに於いてなかったことにすれば計算は楽（考慮しなくてよい）です。ただ、その1秒間の事は記録に残せません。また、時間が過去に戻ります。それが許容できないプログラム（終了時間-開始時間がアンダーフローとか）に気を付けなければなりません。
なんにしても正確な時刻が必要な人（観測系の人とか金融系の人？）は正しく61秒が扱える環境が欲しいわけですが、kernelが対応してもそれを扱えないソフトがあるとバグることに変わりはありません。外部からの入力に関してもそうです。ログに23:59:60.123とかあっても（閏秒の時だけは）エラーにならないとかいろいろあるでしょう。
そして、定義上はどの1秒も1秒としたいでしょう。
といっためんどくさい事から逃れられるのが、UTCはUTに追随しない。差が大きくなったら考える、というもの。
実際UT必要なのは天文系くらいでしょうから（必要ならUTとのオフセット調べればOKだし）それでよいのでは？
Re:定義と実装と運用と (スコア:1, 興味深い)
運用上の話に限定せず、定義から変えてしまえば前者でいいんじゃないか？
1秒の長さを変えて調節した時刻を定義して、全てのコンピュータはそれを使うことにする。
全てのコンピュータがそれを使っていれば、調整前の時間を知りたくなることはまず無いのでは？
調整の期間を十分長く取れば、もともとコンピュータが持ってる時計の誤差よりも小さい調整にすることもできる。
正確な時計を内部に持ってるコンピュータは多くないだろうから、対応は上位のNTPだけで済みそうだし。
1秒の間隔自体が問題になることよりも、1分が1秒増えることの方が遥かに問題になるケースが多いと思う。
調整前の時刻や、調整前の1秒の間隔が重要な場合には、それを使うためのAPIを用意しておけば必要な人はそれを使えばいいだけだし、
そういう特殊なAPIを使うのは、それが必要な一部の分野だけになるから、そうでない分野の人は何も考える必要がない。
この方式だと、UTCからUTに回帰じゃねぇの？ とも思ったけど、
Wikipediaの協定世界時の項 [wikipedia.org]によると、
ということらしいので、やるとしたら、UTCをさらに調整することになるのかな？
ローカルタイム (スコア:1)
どうせ普通の人は地方時(localtime）などという適当なもので生活しているので、その辺をいじるのが良さそうです。UTCとTAIの間はズラさずに、地方ごとの時差をずらすんです。例えば日本標準時だと UTC+9時間 から、UTC+32401秒とかにするとか。
これで閏秒無しでも、生活時間とのズレは最小で済みます。
# 閏秒の挿入の手間に比べれば地方時の変更の手間は少ない...と思う。
# 何千年もたつと日付け変更線を移動させる必要が出てくる可能性がありますが :-)
で、次の調整予定は? (スコア:1, すばらしい洞察)
1972年1月1日0時…現行の協定世界時(UTC) が、UTC = TAI - 10秒 に調整されて開始される。
1972年6月30日…第1回の閏秒調整で、UTC = TAI - 11秒 となる。
2008年12月31日…第24回の閏秒調整で、UTC = TAI - 34秒 となる。
閏秒 - Wikipedia [wikipedia.org]
今までの37年間で24秒分の調整が入っている。単純に同じペースでずれて行くとすると、1時間ずれるまで、あと5550年。
これはつまり、新調整方式というより「みんな文句ばっかり、もうやだ、ボクもう調整したくない」ってことでは…
Re:で、次の調整予定は? (スコア:1)
いや、まてよ。
5000年後も人類が地球上でワイワイやってるとしたら、世界時と国際原子時の差が1秒以内になるように、地球の自転速度を調整するぐらいの事は出来ちゃうんじゃないかな。
つまり、現在ITUが検討している新方式とは「うるう秒を廃止して、地球の自転速度を精密に制御する方式」なのではないだろうか。
二月二十九日に秒も合わせるのが良いと思う (スコア:1, すばらしい洞察)
地球の (スコア:0)
Re:地球の (スコア:1)
微調整？ [afpbb.com]
調整が終わるころにはコンピュータなんてどうでもよくなっていそう。
Re: (スコア:0)
もう、何の映画だったか忘れた...
Re:地球の (スコア:2, 参考になる)
妖星ゴラス [wikipedia.org]ですかｗ
# ちゃんと設定の科学的考証をしてるってことに驚き
逆に (スコア:0)
もっと細かい単位で修正すりゃええんやないの？
Re:逆に (スコア:2)
世界共通のNTPサーバを立てて、みんながそれを参照すればいいですよね。そのNTPサーバは何か宇宙の観測とかで随時微調整ってことで。
世界中のNTPクライアントはslewで時刻合わせすれば事実上いつでも正しい時刻になりますよ。
人生は七転び八起き、一日は早寝早起き
Re:逆に (スコア:1, 興味深い)
標準時の供給側で、1秒を1秒±(1÷(60×60×24×365))にする処理を1年掛けて適用とかにしておけば、大半の機器では誤差。
あとは標準時との同期処理の時に吸収してもらえばそれで済む。
1年1秒程度の誤差(31nsec/1sec)が誤差で終わらないようなシステムは、それこそ数えるほどしか無い。
1ヶ月1秒程度の誤差(0.3μsec/1sec)であっても、実用上ほとんどの機器は問題ないだろうし。
あー、でも同期処理(NTPとか)の真っ最中にやられるとちょっとアレなんだろうか。そこまででもない？
日単位で充分 (スコア:0)
ほとんどの人が忘れたころに、2月29日だけじゃなく2月30日の有る日が出てきたりするのも、まあ、ご愛嬌。
午前と午後の意味合いが変わっても、まあ、良いのじゃないかな。
時間に合わせた方が良い人はそうするだろうし、日照に合わせたい人はそうするだけの話だろ。
Re: (スコア:0)
「ちょうど一日ずれた」になる期間の半分辺りのゾーンは「昼夜逆転」ですが， きっとその時代の人には当たり前のこととなるでしょう。
(20世紀の映画を見たときに「?」となるでしょうけど)
Re:地球が一番えらいの (スコア:1, おもしろおかしい)
>だからみんな地球に合わせないといけないの
そんなふらふらしていい加減なやつにあわせられるか！
#と物理学者は思っております。