アカウント名:
パスワード:
閏秒 ntp が勝手に吸収してくれるから別に気にしなくてOK閏日 さすがに著名なのでどこも対処済み。ていうかライブラリ使えや閏月 もしあったらわりと任意っぽいので扱いは大変そう
かしら
あともう、春分・秋分の日は100年ぐらいのスパンで決定的にしてしまうほうがいいと思うなー
>あともう、春分・秋分の日は
2年先の復活祭の日が確定できないことでカレンダー屋さん、卵屋さんほかの小規模経営がせっせと働く動機を奪わないでそっとしておいてあげるくらいは。。。// そもそも日本では春分秋分の日を大義名分にして拠っているお祭りっぽい固有行事少ないわけだし。
閏秒 → 時間調整のため挿入される秒閏日 → 日付調整のため挿入される日閏月 → 日付調整のため挿入される月閏年 → 閏日や閏月が挿入される年
閏年だけ仲間はずれ。
24:00UTCは、09:00JST。JRの座席予約受付開始なんかは10:00JSTだけれども、09:00始業の会社は多少の混乱が起きそう。前月の5月31日は日曜日なんだから5月末日の方が良さそうな気がするのだが。なぜだろう?
うるう秒は、6月末日か12月末日、それでも足りなければ3月末日か9月末日に挿入されるという決まりになっているからです。
地域によって日付が変わるってこと忘れていませんか? 日曜が公休日でない国もあるし、逆に休日中で無人で動作中にシステム不具合を起こしたら対応するまで時間が掛かるので、「例外的な作業は担当者がいる時に」という見方も。
> 閏秒 ntp が勝手に吸収してくれるから別に気にしなくてOK
調べて書いたの?調べもしないで書いたんじゃないの?
ntp がリアルタイムに時間を調整するから危険が増えます。http://pocketstudio.jp/log3/2012/06/23/leaptime_2012/ [pocketstudio.jp]
ntp がリアルタイムに時間を調整しても問題があるかどうかで問題があるならばntpを止めるかモードを変えましょう。
調べるのは構いませんが,ntpの仕組みが理解できてませんよwww
> ntp がリアルタイムに時間を調整するから危険が増えます。
間違ってます
ntpは安全に時間を調整する仕組みです
元コメントのほうが正しくてntpのデフォルトの挙動が「勝手に吸収してくれる」です
> 間違ってます> ntpは安全に時間を調整する仕組みです
へー。デフォルトモードでも時間を遡りしないっていう資料をください。
ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。プロトコル自体には閏秒の扱いは規定されてる。
> ntp の時刻データとそれ使った時刻同期サービスの話がごっちゃになってるんじゃなかろうか。> プロトコル自体には閏秒の扱いは規定されてる。
で、そのプロトコルに従ってリアルタイムに時刻を変更されると問題が発生する可能性があるみたいですね。
>> ntp がリアルタイムに時間を調整するから危険が増えます。>間違ってます
「ntp がリアルタイムに時間を調整するから危険が増え」るのは間違いないと思うんだけどな。
環境や要件によって,精度(マイクロ秒まで考慮するか否か)や挙動(60秒を許すか否か)など「調整」や「吸収」の定義が違うのに,殴り合ってどうするのですか。
だから
> ntp がリアルタイムに時間を調整しても問題があるかどうかで> 問題があるならばntpを止めるかモードを変えましょう。
と書かれていると思うんだけどな。
> 環境や要件によって,精度や挙動など「調整」や「吸収」の定義が違うのに
安全って言えるんですね?って話だろう?
> 元コメントのほうが正しくて> ntpのデフォルトの挙動が「勝手に吸収してくれる」です
はウソだし
> ntpは安全に時間を調整する仕組みです
もウソじゃない?
って思います。
2012年に痛い思いをしているのでいろいろ安心なんてできません・・・・あのあとLinuxカーネルのパッチでたからもう大丈夫。とは思いたいけど。
でもその後実際に働いた実績が無いわけですよね。今度はカーネルは大丈夫だったけどアプリ側が独自に時刻管理していたのが嵌ったとかあるかも。故あってUpdateがままならないやつが数十台規模であるんだけど、ntpdはslowモードにしておいたほうがよさそうだな。
4年に1回しか実装していなくて2100年問題(2000年は400の倍数だったのでたまたま踏まなかった)を抱えたプログラムがありそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
閏を考える (スコア:2)
閏秒 ntp が勝手に吸収してくれるから別に気にしなくてOK
閏日 さすがに著名なのでどこも対処済み。ていうかライブラリ使えや
閏月 もしあったらわりと任意っぽいので扱いは大変そう
かしら
あともう、春分・秋分の日は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 が勝手に吸収してくれるから別に気にしなくてOK
調べて書いたの?調べもしないで書いたんじゃないの?
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の倍数だったのでたまたま踏まなかった)を抱えたプログラムがありそう。