あるAnonymous Coward 曰く、2015年7月1日にうるう秒が挿入されることが発表された（日本標準時グループ、GIGAZINE）。閏秒廃止論は、今回は無しみたいですね。UNIX時間って閏秒はカウントしてないのね、知らなかった。うるう秒の実施は2012年7月以来で、26回目。
閏を考える (スコア:2)
閏秒 ntp が勝手に吸収してくれるから別に気にしなくてＯＫ
閏日 さすがに著名なのでどこも対処済み。ていうかライブラリ使えや
閏月 もしあったらわりと任意っぽいので扱いは大変そう
かしら
あともう、春分・秋分の日は100年ぐらいのスパンで決定的にしてしまうほうがいいと思うなー
Re:閏を考える (スコア:1)
＞あともう、春分・秋分の日は
2年先の復活祭の日が確定できないことでカレンダー屋さん、卵屋さんほかの小規模経営がせっせと働く動機を奪わないでそっとしておいてあげるくらいは。。。
// そもそも日本では春分秋分の日を大義名分にして拠っているお祭りっぽい固有行事少ないわけだし。
Re:閏を考える (スコア:1)
閏秒 → 時間調整のため挿入される秒
閏日 → 日付調整のため挿入される日
閏月 → 日付調整のため挿入される月
閏年 → 閏日や閏月が挿入される年
閏年だけ仲間はずれ。
Re: (スコア:0)
24:00UTCは、09:00JST。JRの座席予約受付開始なんかは10:00JSTだけれども、09:00始業の会社は多少の混乱が起きそう。
前月の5月31日は日曜日なんだから5月末日の方が良さそうな気がするのだが。なぜだろう？
Re:閏を考える (スコア:1)
うるう秒は、6月末日か12月末日、それでも足りなければ3月末日か9月末日に挿入されるという決まりになっているからです。
Re: (スコア:0)
地域によって日付が変わるってこと忘れていませんか？ 日曜が公休日でない国もあるし、逆に休日中で無人で動作中にシステム不具合を起こしたら対応するまで時間が掛かるので、「例外的な作業は担当者がいる時に」という見方も。
Re: (スコア:0)
> 閏秒 ntp が勝手に吸収してくれるから別に気にしなくてＯＫ
調べて書いたの？調べもしないで書いたんじゃないの？
ntp がリアルタイムに時間を調整するから危険が増えます。
http://pocketstudio.jp/log3/2012/06/23/leaptime_2012/ [pocketstudio.jp]
ntp がリアルタイムに時間を調整しても問題があるかどうかで
問題があるならばntpを止めるかモードを変えましょう。
Re: (スコア:0)
調べるのは構いませんが，ntpの仕組みが理解できてませんよwww
> ntp がリアルタイムに時間を調整するから危険が増えます。
間違ってます
ntpは安全に時間を調整する仕組みです
元コメントのほうが正しくて
ntpのデフォルトの挙動が「勝手に吸収してくれる」です
Re: (スコア:0)
> 間違ってます
> ntpは安全に時間を調整する仕組みです
へー。
デフォルトモードでも時間を遡りしないっていう資料をください。
Re:閏を考える (スコア:1)
ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。
プロトコル自体には閏秒の扱いは規定されてる。
Re: (スコア:0)
> ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。
> プロトコル自体には閏秒の扱いは規定されてる。
で、そのプロトコルに従ってリアルタイムに時刻を変更されると問題が発生する可能性があるみたいですね。
>> ntp がリアルタイムに時間を調整するから危険が増えます。
>間違ってます
「ntp がリアルタイムに時間を調整するから危険が増え」るのは間違いないと思うんだけどな。
Re: (スコア:0)
環境や要件によって，精度（マイクロ秒まで考慮するか否か）や挙動(60秒を許すか否か)など「調整」や「吸収」の定義が違うのに，殴り合ってどうするのですか。
Re:閏を考える (スコア:3)
だから
> ntp がリアルタイムに時間を調整しても問題があるかどうかで
> 問題があるならばntpを止めるかモードを変えましょう。
と書かれていると思うんだけどな。
Re: (スコア:0)
> 環境や要件によって，精度や挙動など「調整」や「吸収」の定義が違うのに
安全って言えるんですね？って話だろう？
> 元コメントのほうが正しくて
> ntpのデフォルトの挙動が「勝手に吸収してくれる」です
はウソだし
> ntpは安全に時間を調整する仕組みです
もウソじゃない？
って思います。
Re: (スコア:0)
2012年に痛い思いをしているのでいろいろ安心なんてできません・・・・
あのあとLinuxカーネルのパッチでたからもう大丈夫。とは思いたいけど。
Re: (スコア:0)
でもその後実際に働いた実績が無いわけですよね。今度はカーネルは大丈夫だったけどアプリ側が独自に時刻管理していたのが嵌ったとかあるかも。
故あってUpdateがままならないやつが数十台規模であるんだけど、ntpdはslowモードにしておいたほうがよさそうだな。
Re: (スコア:0)
4年に1回しか実装していなくて2100年問題(2000年は400の倍数だったのでたまたま踏まなかった)を抱えたプログラムがありそう。
今年が山場 (スコア:1)
> 閏秒廃止論は、今回は無しみたいですね。UNIX時間って閏秒はカウントしてないのね、知らなかった。
むしろ今年が山場で、11月にITUが開催されるWRC-15で決定されます。
この文書(PDF) [itu.int]のP9・10に記載されており、
方針としては以下の３つがあります。
Method A: うるう秒を廃止した連続時系を導入 (名称についてOptionあり)
Method B: 現状のUTC(うるう秒を残す)とうるう秒を廃止した連続時系を"equal basis"で並存させる
Method C: うるう秒を残す (うるう秒を廃止した連続時系を補助的に利用するかでOptionあり)
Method Bになったら、いろいろ悪夢です。
Re:今年が山場 (スコア:2)
連続時系って (スコア:1)
日常生活に影響するほど乖離するまで人類存続しないということ？
the.ACount
Re: (スコア:0)
どっかの国が世界覇権国家になって、「おらの国の首都が世界の中心線だべ」と時刻の定義を書き直すほうが先かなぁ
Re: (スコア:0)
イギリスのこと?
1秒の定義がほんの少し短いのが原因じゃないかと (スコア:0)
26回目もうるう秒を挿入しなきゃいけないなら、1秒の定義をほんの少しだけ長くしたらいいのに。
短い方に補正した例はないんだから。
Re:1秒の定義がほんの少し短いのが原因じゃないかと (スコア:2)
今後短い方に補正する可能性はゼロではないですね・・・自転周期は地球の構造上中心部が液体であること、潮の干満と海底との摩擦により、長期的には自転速度はだんだん遅くなっています [wikipedia.org]し、そもそも自転周期は不規則に変動している（一定ではない）ので、「閏秒が必要ないように」かつ「現在の各種インフラを維持できる精度で」定義を変えるというのは難しいでしょうね。
地球の自転周期で1日を定義しようとすると、10^-8日（*60*60*24≒ミリ秒）程度の精度しかないそう。
なお、抜く必要が出る頃に人類が地球上にいるかは私にはわかりかねますが。
Re:1秒の定義がほんの少し短いのが原因じゃないかと (スコア:4, すばらしい洞察)
東日本巨大地震の影響で地球の自転が速まる [srad.jp]なんて話もありましたね。
#Wikipediaにも書いてあるけど、スラドでもネタになったことあるよということで
Re:1秒の定義がほんの少し短いのが原因じゃないかと (スコア:1)
うるう秒は測定誤差から来てるんじゃなくて、地球自体の回転の鈍化が原因。
だから、今の回転速度に合わせて秒の長さを再定義しても、何年か経ったらまたうるう秒を挿入しなければいけない。さすがにそれは筋が悪すぎる。
Re: (スコア:0)
＞地球自体の回転の鈍化が原因。
それ、誤解。
今後の長期的観測を待たないと断定的なことは言えないけど、近年の地球の自転速度はむしろ早まってます。
仮に「一日に2秒進む時計」があったとして、一月に一度1分戻し続けなければズレが溜まってしまうわけで、
今はそういう状態。
この進みが「一日に2.1秒」、「一日に2.2秒」… と増えていくのであれば「自転の鈍化」言えますが、
近年の観測ではむしろ「一日に1.9秒」、「一日に1.8秒」… と時計の進みが減っている傾向です。
このままの状態が続けば、徐々に閏秒を挿入する間隔は長くなり、長期にわたる「閏秒不要の時代」を経て、
いずれ「閏秒の削除時代」がくるかもしれません。
「自転速度の鈍化」がなくても、一定のズレがあり続けるだけで、閏秒挿入の必要もあり続けます。
Re: (スコア:0)
ここ [wikipedia.org]には「地球の自転は減速傾向にある」と書かれているのですが
加速しているというのはどの文献ですか？
Re: (スコア:0)
その ここ [wikipedia.org]に「ここ40年間では、一日の長さ（LOD）はむしろ短くなっている（地球自転速度が速くなっている。）」と。
まあ、1秒の基準にした頃よりは回転が鈍化しているというのは違いないが、グラフ [ucolick.org]を見ると1972年頃が一番速かったようです。
しかしなぜ1956年に秒の長さを決めたときに、その時点でのLODではなく1750年から1892年までが基準になったんだろう？
その頃は鈍化中だったので、過去に遡った基準点にする
Re: (スコア:0)
訂正。(図中では)1972年頃が一番遅く、速いのは2004年頃でした。
Re: (スコア:0)
暦 の秒の定義だけ変えちゃったから仕方ない。
元が地球一回転基準ですからねぇ。
最終的には回転速度調整しかありませんな。
Re: (スコア:0)
宇宙エレベータをいっぱい作ったら...
遅くする方にしか調整できないか。
「コンピュータシステムの61秒問題」 (スコア:0)
2015年6月30日にうるう秒が挿入されることになりました。
通常のシステムでは、秒は0～59までの値を取る前提に作成されていますが、これに60という数字が入ることにより、
御社のコンピュータシステムが誤作動する可能性があります。
最悪の場合、システムの停止、データの喪失、データ化けが発生し、
取り返しのつかない状況になる場合がございます。
当社では、他社の作成したシステムでも、格安で改修を行っております。
調査・改修の見積もりは、下記の電話で受け付けております。
すぐにお電話ください。
会社名： あやしいシステム
TEL： 090-xxxx-xxxx
Re: (スコア:0)
60進数の言語環境とか、何の役に立つと思って設計したんだろう。
あっ...
時報どうなってるの？ (スコア:0)
０時０分、丁度を、おしらせします。…ぴ、ぴ、ぴ、ぽーん、ぽーん…とか、ぽーんが２個入るのかな？だれか聞いた人いませんか？
Re:時報どうなってるの？ (スコア:1)
時報の100秒前から101/100秒刻みで鳴らす話はずっと昔およそ半世紀前からお決まりの方法。
これってntp の skew モードと似たものだといっていいのかなあ?
// というわけで(#2741891)が思いついたようなことにはならない。
Re:時報どうなってるの？ (スコア:1)
いやそれ、NTTの場合だと2009年1月1日実施の第24回閏秒調整までみたい [wikipedia.org]ですよ。
【別紙】加入電話、ＩＮＳネット（電話サービス）とひかり電話（電話サービス）のうるう秒における時報サービス「１１７」のガイダンスについて [ntt-east.co.jp]
Re:時報どうなってるの？ (スコア:1)
今世紀最初のジェネレーションの変化を知らないままだった不明を恥じます。
(#2741891)には申し訳ありませんでした。
Re: (スコア:0)
ひかり電話のこの仕様(時報音が60秒00秒の二回)ってなぜこうなったんだろう？
知らずにたまたまこれで合わせようとしたら、合わせられないですよね。
Re: (スコア:0)
ぽ、ぽ、ぽ、ぽーん、ぽーん。
23時59分60秒 (スコア:0)
通常存在しない60秒という時刻を挿入するのと、59秒を2回やるのでは、どっちの方がシステムに与える影響が少ないんですかねえ。
Re: (スコア:0)
時刻をキーにしているDBがありそうだから、59秒が2回刻まれるの方が痛いかと。
むろん、60秒を例外扱いしないよう組んである必要がありますが。
Re: (スコア:0)
それが為に59秒が2回刻まれるとまずいことが起こるなら、1秒以内に2回そのイベントが起きないことが保証されていることが必要。
1秒以内に2回起きないことは保証していて、2秒以内に2回起きないことは保証できないといのは限定的だと思う。
でも、59秒が2回刻まれると秒未満での時刻の遡行が起こるので重大な影響になる(2012年には実際起きたようで）。
一方、time構造体中の秒は古えより「int型の0～60」と定義されているので、よもや60秒を考慮していないなんてない。はず。きっと。多分。だといいなぁ。