8時59分60秒
執筆日時：
今年の7月1日は 1秒 長い日となります
今年の7月1日だけ8時59分60秒があるだなんて、ちょっと素敵で不思議。けど、不思議では済まないのが融通の効かない計算機の世界。たったこれだけのことで、計算機の世界はちょっと混乱してしまう。
Windows オペレーティングシステムでは、うるう秒の処理をおこないません。たとえば、「yyyy/mm/dd 08:59:60」の年月日時刻情報につきましては、Windows OS ではサポートしていません。このため、たとえば「2012/7/1 08:59:60」は「2012/7/1 09:00:00」として処理されます。
InfoQ: Windows Azure がうるう年処理のバグによってダウン で少し名誉を傷つけられた Microsoft の場合。
Windows では、うるう秒については基本的に対応せず、2012/7/1 08:59:60 は存在しないものとして扱われる。必然的に1秒のズレが生じるが、一般的な用途ではあまり問題がない。1秒のズレは、いずれかのタイミングで“time.windows.com”*1と同期され、ユーザーが気づかないうちにこっそり自動補正される。
けれど、まったく問題がないわけではない。「2012/7/1 08:59:60」を扱うシステムが Windows と連携する場合は、なにか起こるかもしれない。
たとえば、Microsoft SQL Server は「2012/7/1 08:59:60」というデータの入力を受け付けないけれど、それを行おうとしてハングアップしてしまうアプリケーションがないとはいえない。
内部動作とは別に、外部からうるう秒を加味した時刻を受け取る可能性がある例として iCalendar 形式の予定がありますが、Exchange Server が iCalendar 形式の予定を受信する際、時刻の表記は RFC5545 に定義されている形式のみをサポートします。うるう秒を考慮した秒の表記は 0 から 60 までがサポートされ、それ以上の秒数が記述されている場合は不正な形式として処理され、正しい iCalendar 形式とは見なされません。
Outlook につきましては、60 秒の場合は 0 とみなしますので、2012/07/01 08:59:60 は、2012/07/01 08:59:00 となり、最大で 1 分のずれが生じる可能性がございます。
メールの受信の順番がずれて見える可能性がございますが、動作に影響はありません。
この程度のエラーならかわいいものだけど。
また、NTP サーバーと同期を行う一部の UNIX系のOSでは部影響があるようだ。
時刻差を強制的に同期させるモード（STEPモード）では、うるう秒挿入のタイミングでミリ秒単位の時刻の逆進が発生しますので、ミリ秒単位で時刻を扱っているミドルウェアやアプリケーションへ影響が生じる可能性があります。
2009年1月1日の「うるう秒」挿入に伴う富士通Solarisサーバへの影響について
http://jp.fujitsu.com/platform/server/unix/soft/time2009-solaris-server.pdf
本来、時間というものは順番に来るもので、当然、アプリケーションは暗黙にそれを前提としている。なので、たとえミリ秒単位であったとしても、逆進が起こるのはあまり望ましくない。そんなわけで、なかにはちまちまうるう秒を挿入しないで、あとでまとめてドバっと調整してしまおうぜ、という意見もあるらしい（「うるう秒」廃止へ ? ITU が新方式を検討中 | スラッシュドット・ジャパン サイエンス）。
たった一秒でも、いろんな議論があるもんだ。たった一秒の Leapなど、ほとんどの人は意識しなければ気づかないだろうのに。
*1:ほかのNTPサーバーへカスタマイズすることも可能