HN4855
【技術者必読】史上初の「負のうるう秒」が来る！あなたのシステムは耐えられますか？
Ask HN: Are systems ready for the first negative leap second?
Asmod4n・5日前
議論
11件前回のうるう秒挿入から10年が経過し、ついに史上初となる「負のうるう秒（negative leap second）」の導入が現実味を帯びてきました。現在稼働中のシステムは、この未知のイベントに対して準備ができているのでしょうか？
システムは全く準備できてないよ。うるう秒なんて悪手だし、負のうるう秒ならもっと最悪だ。そんなことせずに、ドリフトが打ち消し合うように放置しておけばいいんだよ。
Googleの提案はごまかしでしかない。[1] ほとんどのタイムサーバーはスミアリングを使ってないし。サブ秒単位の時間が重要な場所で、どんな挙動を引き起こすか見当もつかない。こういうバグ[2]が「時間を逆行させること」に対処するためだけに修正されたのか気になるな。
正と負のうるう秒があるなら、そもそも何のためにやってるんだ？10年後に1秒戻すために、わざわざ1秒進めるってどういうことだよ…
実際に気にしてるシステムってどれくらいあるんだろう？主要なNTPサーバーはうまく処理してるだろうし、ほとんどのシステムはそこから供給を受けてるだけじゃないか？
GPS衛星も問題ないだろうけど、コンシューマー向けや産業用のGPS受信機はどうかな？トレーディングシステムとかは怪しいかも。暗号システムあたりはあまり気にしてなさそうだけど。
そういうシステムには責任持てないな。
前回この話が出た時、1日かけて秒を「スミア（引き伸ばし）」すれば、時計が突然±1秒ズレる問題は解決するんじゃないかと思ったんだけど。
個人的には準備できてると思う。gettimeofday()は時間の測定に使うべきじゃないけど[1]、負のうるう秒なら単調増加は維持できるしね。
お粗末なコードが100msの処理を1100msかかったとか判定するようになるだろうけど、-900msになるよりはマシだろ。
まあ、そうは言ってもリンク先にある通り、F5のロードバランサーは少なくとも以前はgettimeofdayでTCP接続を追跡してたし、libpcapがメタデータをウォールクロックで出しちゃうのはイライラするね。
[1] https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html
どうせうるう秒システム自体が2035年までには廃止されるんだから、わざわざテストする人がいるとは思えないな。たかだか1秒のために波風立てる必要なんてないでしょ。
負のうるう秒なんて実行されるとは思えないけどな。
2027年初頭には「うるう時間」に変える投票がされるはず。技術的な悪夢を続けさせるより、そっちのルートに行くことになると思うよ。
実際の恒星日と合わせる調整なんてやめて、純粋なUTCにしてほしい。16時に起きて8時に寝る生活になったとしても、それはそれで構わないし。
安心させてあげるけど、Unixエポックタイムにはこの問題はないんだ。でも、その理由を知ったらゾッとするかもしれないよ。
まず、エポック秒は「1970年1月1日からの秒数」じゃない。あれは子供向けの嘘だ。実際には「1970年1月1日からの日数×86400」に「深夜からの秒数」を足したものなんだよ。
エポックタイムにとってうるう秒は存在しない。二重カウントされてるのか、12時間や24時間かけてスミアリングされてるのか（しかもGoogle、Microsoft、Oracleでその時間枠が違うというデタラメぶり）。結局のところ定義されてないから、実装ごとにバラバラなんだ。
負のうるう秒ならもっと簡単かもしれない。仕様上はうるう秒のせいで1日の秒数が86400未満になるから、まともな実装なら単にスキップするはず。もちろん、スミアリングしてる組織はそこでも強引にスミアするだろうけどね。
じゃあ2つのエポック間の秒数が本当に知りたい時はどうするか？エポック秒を引き算するだけじゃダメなんだ。その間のうるう秒の分を補正しないとね。あとスミアリングの分も忘れずに。