役に立ちそうな情報この辺りのサイトは見ておくと理解の助けになるかと思います。うるう秒に対応する方法がまとまっています。使用する際の細かい動きがまとまっています。動きについてとても参考になりました。今回の事象は、事前に防げなかったのでしょうか。プロジェクトチーム、サービス事業社さん等でも、事前に調査された方もたくさんいらっしゃったと思います。これまで何度かあったうるう秒挿入で、検証方法等もだいぶ確立されていたのではないでしょうか。今回の事象は事前に発見できなかったのでしょうか。個人的には、今回の障害は、事前に発見することは困難だったのではないかと思っています。擬似的に発生させたり日付を手動でうるう秒挿入直前に変更して、正しくうるう秒が挿入されることを確認して終わることが多いでしょう。アプリケーションを実行していないと発覚しないものでした。使用率が高騰する、というものだったので、ある程度時間をかけて継続的にモニターしないと発見できなかったでしょう。理想的には、時刻修正の確認だけでなく、アプリケーション含め統合テストをやり直していれば発見できたかもしれません。あらゆるプロジェクトでうるう秒確認のために統合テストをやり直すのは、現実的には不可能でしょう。カーネルのコードを開発する際に、変更した部分は単体テストして、問題ないことを確認しておくべきなのでしょう。ハードウェアに近い場所で動くソフトウェアの場合は特に、全てのパスを網羅できるようなテストケースを用意するのは困難な面もありますが、これはひとつひとつ地道に増やしていくしかないのかもしれません。同じ問題は今後は発生しないだろうと期待できます。thread#46)。カーネルのように更新頻度の高いソフトウェアの場合、「前回のうるう秒では大丈夫だったから」という言い訳も通用しないのがつらいところです。問題が発生しています。タイマー周りのコードが変化し続ける限り、うるう秒のたびにきっちり検証を続けていくしかなさそうです。つのモードがあります。モードは一気に時刻をずらすためにすぐに時刻が正しくなりますが、アプリケーションから見て時間の逆行が発生する可能性があります。モードの場合は、徐々にずらしていくことで時間の逆行を可能な限り発生しないようにするものの、時刻の同期に時間がかかります。使用率高騰のトリガーになっていました。モードでの時刻同期が前提になっています。ミリ秒となるため、同じ現象が発生する確率はだいぶ小さくなったかもしれません。モードを勧めるつもりは全くないのですが、あくまで「たられば」の妄想としてメモしておきます。うるう秒挿入ビットをセットしないようです。モードに設定していた場合、そもそもこのような問題は発生しなかった、ということになります。最後に間違いの指摘やご意見などありましたら下記までご連絡いただけると助かります。@orimanabu。