時を欠ける症状−うるう秒から考えるサステナビリティ：安藤幸央のランダウン（44）

「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部）

[安藤幸央（[e-mail]），＠IT]

2009年1月1日、“うるう秒”はなぜ起こった？

　2009年1月1日9時に、うるう秒が挿入されました。これは2006年以来、3年ぶりのうるう秒です。読者の皆さんは「うるう秒」と聞いて手元の腕時計を気にしたりしませんでしたか？ 今回のうるう秒は日本時間 2009年1月1日午前8時59分59秒の次に60秒として挿入されました。

　そもそも“うるう秒”は、なぜ必要なのでしょう？

　大昔、時間や時刻は、地球の公転・自転に基づく天文時が使われていました。近年になり科学の進歩に応じた高精度な時刻が必要になりました。

　現在使われている時刻は、原子時計を基に決められています。地球の自転は一定ではないので、天文時には変化があります。規則正しい原子時計と地球の自転に基づく時刻の差が常時±0.9秒以内になるように、協定世界時（UTC）では原子時計の時刻に適宜1秒だけ調整を行います。現在、この時刻が世界の標準時として一般に使われています。うるう秒とは、UTCで適宜調整する1秒のことです。

　うるう秒の調整は6月30日か12月31日に行い、挿入の場合は23:59:59の次に23:59:60を挿入し、削除の場合は23:59:59を削除します。

ITシステムへの影響

　1ミリ秒を争うリアルタイムシステムや、テレビやラジオの放送の世界では、「1秒」はとても重要な時間でもあります。その一方、1秒の違いはそれほど重要ではないシステムも存在します。

　ほとんどの水晶振動素子によるコンピュータクロックは、うるう秒の違いを反映できるほど正確ではありません。また時刻の正確性を必要とする大抵のコンピュータはNTPによって時刻の同期を行っています。

□そもそも、NTPとは？

　NTP（Network Time Protocol）は、ネットワークに接続される機器において、機器が持つ時計を正しい時刻へ同期するためのプロトコルです。一般的なOSでは、NTPサーバ・クライアントモデルのクライアントに相当する機能を持ちます。それらのOSはNTPサーバへアクセスし、機器内部の時計の時刻をNTPサーバの時刻に合わせることで内部時計の誤差を少なくするように努めます。またNTPは、ネットワークを経由した通信時間による時刻値の誤差を小さくする工夫が施されています。

　日時によってアプリケーションの使用期限を管理しているライセンスサーバなどの場合、注意が必要です。外部からの要因で日付が変わると、ライセンスが無効になる場合もあるからです。

□GPSの場合

　GPS衛星は1980年1月6日0時からカウントをスタートした時刻で扱われます。IAT（International Atomic Time、国際原子時）に基づき、うるう秒を数えません。GPS受信機は、うるう秒更新の日時を考慮した作りになっています。

□UNIXの場合

　内部では1970年1月1日0時0分0秒からの秒数で表現されているため、日時表現にする際にうるう秒を考慮して変換します。正確に時刻を合わせるためにはUNIXカーネルのUNIX timeを調整する必要があります。

　例えば、うるう秒に対応している環境（Red Hat系Linuxなど）では、「Clock: inserting leap second 23:59:60 UTC」といったログが残ります。

□Windowsの場合

　「うるう秒に関する Windows タイム サービスの処理」を参照してください。

□Solarisの場合

　xntpdの設定によって変わります。ntp.confへの設定が必要な場合もあります。Solaris 6、7、8はパッチが必要な場合がありますが、Solaris 9ではパッチは必要ありません。

□Javaの場合

　Javaで時刻を表すAPI（例えば、java.util.Date）では仕様上、秒数を表すメソッドで0〜61秒を表現できます（JDK 1.0 以降）。実際には、うるう秒を正確に追跡する必要があるJavaの実装でのみ使われます。

□Oracleの場合

　「16785:システム時刻の変更にともなう注意点」「33273: うるう秒について」を参考にしてください。

いまさら聞けない「2000年問題」

　時刻に関するIT／システムへの症状といえば、2000年問題が有名です。2000年問題とは、西暦の年号を下2けたで管理（例えば、1998年を「98」で管理）していた場合、「00」にカウントが増加した際、1900年として扱われることを原因とする問題です。

　2009年のいまでこそ笑い話ですが、その当時は大騒ぎになりました。銀行システムがすべてダウンするとか、運行管制をコンピュータに頼っている乗り物が止まったり、航空機が落ちるとか、大変多くの心配事に悩まされました（中には、本当に笑い話で済まなかった正月返上で苦労されたシステム管理者がいらっしゃったかもしれません。お疲れさまです）。

　当時はプログラム開発言語の関係や、メモリ容量やデータ記述容量を小さく済ませるために、本来4けた以上の西暦の数値を2けたで扱ったのです。

　また問題となるシステムが開発された当時の1970〜1980年代には2000年は遠い未来で、2000年を超えて使い続けられると考えていなかったのかもしれません。

これから実際に起こるかも？ 時を欠ける症状たち

　2000年問題を教訓に、これから起こるであろう時間系の問題に少しでも対策が講じられれば幸いです。

□8カ月後−2009年問題

　2009年9月21日は敬老の日です。さらに、ハッピーマンデー施行後初の9月の休日となります。9月には国民の休日はないものとして実装されているシステムがあれば、休日の判定に異常を生じる可能性があります。

□16年後−2025年問題（昭和100年問題）

　年数を昭和の下2けたで管理しているシステムの場合、2025年に「昭和100年」といった具合に、“けたあふれ”を起こす問題です。そもそも平成のいまでも、そのまま使い続けている方が問題なのかもしれませんが……。

□29年後−2038年問題

　UNIX系OSのtime_t型（1970年1月1日0時からの経過秒数）が2038年1月19日の3時14分7秒に“けたあふれ”を起こす問題です。アプリケーションレベルでの対応が難しく、問題視されています。

□71年後−2079/2080年問題

　Windows/DOSのFATシステムを扱う古いOSやソフトウェアでファイルの年号の下2けたが80〜99の場合、1980〜1999年と認識する。また00〜79の場合、2000年〜2079年と判別しているものがあります。そのため、2080年1月1日以降ファイルのタイムスタンプ関連で誤作動を起こす可能性がある問題です。

時間系問題の6つの処方せん

　今回のうるう秒に限らず、うるう年や休祝日判定など日時や時刻のコンピュータ上での取り扱いは、単純そうに見えて、とても複雑なものです。予想し得ない事項も含め、これから起こる問題すべてに対処するのは不可能です。少なくとも「いついつに不具合が起こる」ということが分かっている場合は、放置せず適切な対応と対処を心掛けましょう。

　以下に、無用の苦労を避けるためのポイントを挙げておきます。

時間系問題の6つの処方箋

• できるだけOSやプログラム言語の標準APIを使う。変に自作しない
  まれに標準APIの実装自身が間違っていることがあるが、実際に問題が起こる日付までには、パッチなどで修正される可能性が高く、安心できる
• 何事も決め打ちしない
  「年号を下2けたで扱う」「休日はいついつ」など、すべての事象は今後変わることを前提として考えて設計しておく。休日は国によって異なるし、法令や勤務形態によって、休日は毎年変化する
• 適切なテスト計画のうえで、網羅性の高いテストを
  コンピュータの設定時間を未来の日時にずらして動作を確認。特に、うるう年や年末年始、次の年の休日などは重点を置くべきテスト項目となる。また、入力される年月日時分秒のチェックを怠ってはいけない。すべての事象を検討するのは、コストに見合わない場合もある（例えば、西暦10000年に正しく動くかどうか試すのはほとんどの場合無意味）
• ユーザーインターフェイスで回避
  自由に月を選べる入力フォームよりも、1〜12のプルダウンメニューで選択する方が、入力値が絞られるため、エラー処理が簡単になる。この方法がユーザーインターフェイス的に必ずしも使いやすいとはいえない場合もあるが、入力エラーを減らすというアプローチは正しい方法
• 数年後に万が一不具合が起こった際、修正できる余地を残しておく
  データ記述領域に予備フィールドを用意しておくなど。予想外の事象のために冗長性を確保しておく
• 数年後に作り替える、バージョンアップすることを前提として作る
  始めから、数年運用するものと限定し、その範囲内で厳密なテストをする

サステナビリティを、お大事に

　そのほか、最近リリースされたWebブラウザOpera 10は、JavaScriptなどで、Webブラウザのバージョンを判定している仕組みの中で、古いものでは「Opera 1」と誤判定してしまうことが心配されています。

　エコシステムの中では「サステナビリティ（持続可能性）」がよく取り上げられます。コンピュータシステムにおいても、いままでももちろんのこと、これからも「サステナビリティ（持続可能性）」はとても重要な要素になってきます。

　2000年問題をなんとか乗り切れたからといって、安心してはいられません。ますます複雑化するシステムをより安定して使い続けられるように、皆が将来のことを考えて行動しなければいけないのかもしれません。

　次回は2009年3月初めごろに公開の予定です。内容は未定ですが、読者の皆さんの興味を引き、役立つ記事にする予定です。何か取り上げてほしい内容などリクエストがありましたら、編集部や＠ITの掲示板までお知らせください。次回もどうぞよろしく。

■関連書籍

• 「暦と数の話−グールド教授の2000年問題」早川書房（スティーヴン・ジェイ グールド著）

プロフィール

安藤幸央（あんどう ゆきお）

1970年北海道生まれ。現在、株式会社エクサ マルチメディアソリューションセンター所属。フォトリアリスティック3次元コンピュータグラフィックス、リアルタイムグラフィックスやネットワークを利用した各種開発業務に携わる。コンピュータ自動彩色システムや3次元イメージ検索システム大規模データ可視化システム、リアルタイムCG投影システム、建築業界、エンターテインメント向け3次元 CG ソフトの開発、インターネットベースのコンピュータグラフィックスシステムなどを手掛ける。また、Java、Web3D、OpenGL、3DCG の情報源となるWebページをまとめている。

ホームページ
Java News.jp（Javaに関する最新ニュース）

所属団体
OpenGL_Japan (Member)、SIGGRAPH TOKYO (Vice Chairman)

主な著書
「VRML 60分ガイド」（監訳、ソフトバンク）
「これがJava だ! インターネットの新たな主役」（共著、日本経済新聞社）
「The Java3D API仕様」（監修、アスキー）