次の 7 月 1 日・日曜日朝に閏秒（うるうびょう） leap second が挿入される。
閏秒とは，UTC（協定世界時）の取り決めにおいて，国際原子時の時刻計測に則りつつ，世界時との時刻差を常に ±0.9 秒以内に保つように UTC に対して行う時刻調整である。国際原子時はセシウム（福島原発事故以降，あんまり聞きたくない原子名）の原子間振動周波数に基づく時刻計測による原子時計の時刻で，数十万年に 1 秒狂うかどうかという高い精度をもつ。一方，世界時は地球の自転に基づく時間で，月，海流，地殻変動等の宇宙空間ないし自然現象の影響で変動する要素が強いが，地球が 1 回転したら 1 日という人間の原初的時間観念に合っている。UTC を原子時に合わせていると世界時との時間差が拡大するので，何年かに 1 回，1 秒（つまり閏秒）を挿入（もしくは削除）することでこの差を ±0.9 秒以内に保つわけである。前回の閏秒挿入は UTC 2008 年 12 月 31 日 23 時 59 分 59 秒の次だった。
来る UTC 2012 年 6 月 30 日 23 時 59 分 59 秒の次の秒単位時刻は 2012 年 7 月 1 日 0 時 0 分 0 秒ではなく，閏秒が挿入されて 2012 年 6 月 30 日 23 時 59 分 60 秒になる。そしてその 1 秒後に 2012 年 7 月 1 日 0 時 0 分 0 秒になるのである。JST（日本標準時）は UTC との時差が ＋9 時間なので，日本では 2012 年 7 月 1 日 8 時 59 分 60 秒という 1 秒間が挿入されることになる。NTT のひかり電話を使っている人なら，この瞬間の時刻サービスで通常は 1 回のポーンを 2 回聞くことができるはずである。つまり，ピッ（57），ピッ（58），ピッ（59），ポーン（0）が，ピッ（57），ピッ（58），ピッ（59），ポーン（60），ポーン（0）である。
さてこの閏秒，計算機システムにも影響を与えるのは言うまでもない。OS あるいはライブラリのレベルでは，23 時 59 分 60 秒に対して正常に動作する対応は当たり前のようにできていて，ネットなんかでは Linux や glib の閏秒への対応に言及している記事をよく見かける。しかし，それで「Linux なら閏秒に対応しているので問題ない」などという思い込みをするのは，「愚か」というべきである。システムはアプリの末端まで正常に首尾一貫して矛盾なく動作してナンボなわけで，Linux 端末に 23 時 59 分 60 秒を表示させて「ほぉ」と喜ぶためではないからである。逆に，「23 時 59 分 60 秒」なんて時刻を返してくれずそのためにシステム時刻が 1 秒進んでしまうほうがありがたいこともあるくらいである。そう，私のような SE からすれば，ヘタに「60 秒」なんかシステムから返されないほうがよっぽどありがたい。だいたいのアプリは「60 秒」という時刻データを受け取ると気が狂うようにできているはずだからだ。
つまり，普通の業務システムでは閏秒を考慮した設計になっていないのが現実であって，それはシステム設計者が必ずしもヘボなわけでなく，ただシステム構築に使える金と時間の制約によるものである。アプリを閏秒対応したところで，どだいどうやって試験するのだ？
あるイベントを一意に管理するためにシステム状態管理プログラムで時刻を使うことは頻繁にある。たとえば，ユーザ登録処理で新規ユーザの管理情報として処理時刻を埋めたキーを生成するような場合がある。そのとき，時刻の秒部分を 0〜59 の範囲内で数値チェックしていると，たまたま 8 時 59 分 60 秒に処理がぶち当たった場合 60 というキー値がエラーになり，システムが正常動作しない。この他，NTP（タイムサービス）の時刻の差分とプログラム内部のタイマによる計測時間とで時間の不一致が起こり，システムに矛盾が発生することだって想定される。通常の 1 時間は 3,600 秒で 1 日は 86,400 秒であるわけだが，閏秒を挿入しても 3,601 秒，86,401 秒にできない事情が問題をさらに複雑にする。時間課金を採用しているシステムなんかは金が絡むだけ大問題に発展する。
閏秒問題はこのとおり，放置すると何が起こるかわからない。放置できないが，影響調査をした上でプログラム対策をする？ そんな金と労力の無駄遣いは普通しない。23 時 59 分 60 秒前後の時間帯だけシステムを一時停止させればよいのである。IPL でもう一度システムが起き上がったときシステム時刻は NTP に再度追従をはじめる。あるいは NTP とは無関係に自分の時間で動きはじめる。それは通常運用と何も変わらない。来る 2012 年 7 月 1 日 8 時 59 分 60 秒は幸いにも日曜日朝。たいていの業務システムは大きな影響なしに止められるはずである。私の顧客ではすべて，閏秒挿入前後ではシステムを停止いただくことで，調整は何の問題もなかった。
止めてはいけない超高信頼・超高可用性要求の超高価システムで，不幸にも，あるいは愚かにも閏秒を考慮していなかったという場合は，運用でトランザクションの入口だけ一瞬閉塞させるとか知恵を絞ってください。もう十分検討しているはずでしょうけど（他人事）。