そういう動作をする場合もあるようですが、ntpdにはleap indicatorの実装があるため、通常は上位ntpサーバから流されるleap bitを受け取り、これを解釈して明示的にうるう秒を挿入します。つまり長い1秒ではなく、追加の1秒を挿入します。
Linuxの場合、さらにtzdataパッケージにうるう秒挿入予定が記載されていれば、local timeとしてxx:xx:60が表現されます。記載が無い場合はxx:xx:59が2回繰り返されます。
2012年のうるう秒挿入ではバグによるkernel panicが多発したため、leap bitを受け入れない設定で動作しているホストも多いと思いますが、その場合はうるう秒が発生した後で徐々に上位サーバとの同期を取り直す動作になります。収束までの時間は構成によりますが概ね30分〜1時間程度掛かります。
事前に1秒の長さを伸ばして帳尻を合わせるのは電話時報などです。NTTの場合は100秒前から1秒表記の間隔を1010msに延長します。
補足ありがとうございます。私などよりはるかに素晴らしい専門知識をお持ちで参考になります。
leap indicator の話まで行くと私の知見レベルではただの下手な説明になるので省略しましたが、代わりに簡潔かつ正確に説明頂いて感謝です。
私の認識では、世の運用中サーバは殆どが、うるう秒をまともに扱うようなまっとうであれど危険であることはせず、SLEWモードで無視するだろうと勝手に思っていたのですが、ちょっと不安になって改めて調べてみたところ、どうやらAWSは SLEW と STEP とシステムによってバラバラのようです。
AWS でのうるう秒対応 - Qiitahttp://qiita.com/yyoshiki41/items/d63dbbb5d4bc8e38719a [qiita.com]
ConsoleはSLEWらしいので元コメの課金の話は「うるう秒でも１秒多く課金はされない」が正解のようですが・・・こんなバラバラとは思ってませんでした。恥ずかしながら長文だらだら書く前に検索しろって話でしたね。失礼しました。
最初のバージョンは常に打ち捨てられる。
Re:うるう秒の時 (スコア:3, 興味深い)
そういう動作をする場合もあるようですが、ntpdにはleap indicatorの実装があるため、通常は上位ntpサーバから流されるleap bitを受け取り、これを解釈して明示的にうるう秒を挿入します。
つまり長い1秒ではなく、追加の1秒を挿入します。
Linuxの場合、さらにtzdataパッケージにうるう秒挿入予定が記載されていれば、local timeとしてxx:xx:60が表現されます。記載が無い場合はxx:xx:59が2回繰り返されます。
2012年のうるう秒挿入ではバグによるkernel panicが多発したため、leap bitを受け入れない設定で動作しているホストも多いと思いますが、その場合はうるう秒が発生した後で徐々に上位サーバとの同期を取り直す動作になります。
収束までの時間は構成によりますが概ね30分〜1時間程度掛かります。
事前に1秒の長さを伸ばして帳尻を合わせるのは電話時報などです。NTTの場合は100秒前から1秒表記の間隔を1010msに延長します。
Re:うるう秒の時 (スコア:3)
補足ありがとうございます。
私などよりはるかに素晴らしい専門知識をお持ちで参考になります。
leap indicator の話まで行くと私の知見レベルではただの下手な説明になるので
省略しましたが、代わりに簡潔かつ正確に説明頂いて感謝です。
私の認識では、世の運用中サーバは殆どが、うるう秒をまともに扱うような
まっとうであれど危険であることはせず、SLEWモードで無視するだろうと
勝手に思っていたのですが、ちょっと不安になって改めて調べてみたところ、
どうやらAWSは SLEW と STEP とシステムによってバラバラのようです。
AWS でのうるう秒対応 - Qiita
http://qiita.com/yyoshiki41/items/d63dbbb5d4bc8e38719a [qiita.com]
ConsoleはSLEWらしいので元コメの課金の話は「うるう秒でも１秒多く課金はされない」が
正解のようですが・・・こんなバラバラとは思ってませんでした。
恥ずかしながら長文だらだら書く前に検索しろって話でしたね。失礼しました。