うるう日トラブル

昨日は「2月29日」で、4年に一度の「うるう日」。日付けデータというのは、プログラミングのデータ用その中でも結構重要で、パソコンの時計情報から月・日・曜日の取得何て言うのは、プログラミング教育の最初の最初に教わる内容。で、単にデータを取得して終わりではなく、それを処理するときには「うるう年」の判定が落とし穴で、これで期間日数の計算の時などにに「2月29日」を忘れて失敗することがあります。

単純に4年に1回、西暦の年数が4で割り切れる年の2月の日数が28日から29日になるだけならまだしも、その「4年に一回」の条件に、さらに「100で割り切れる西暦の時にはうるう月にならない」かつ「400で割り切れる西暦の時にはうるう月を設定する」という2つの条件がさらに追加されるからややこしい。「2000年問題」の対応で1999年に大騒ぎになったけれど、この2000年という年は、本来は4年に一度の「うるう年」の時なんだけれど、100で割り切れるうるう年に当たらないと思いきや、400で割り切れるから「うるう年」として扱うという微妙なタイミング。後から聞いたら、その100年、400年の例外処理を知らずに、単純に「4年に1度のうるう年」として処理していたという事例も結構おおかったらしい。結果的には「うるう年」として処理されるわけだから、違いは無いのだけれど、結構危ない気がします。

まぁ、プログラミング的には幾つかの例外処理を入れないといけない条件なんだけれど、昔からある話だしそんなに難しい処理でもないし、それがなんで今回いろいろとトラブルになるのかちょっと不思議な感じがします。ぶっちゃけた話し、100年、400年の例外判定を入れなきゃいけないのは、次は2100年になるわけだから、正直今は知っているソフトはその頃にはもうなくなっている気がします。割り切って「4年に1回」だけの判定でも良いと思うけれど、テストケースで2100年とか2400年とか流す意地悪なテスターとか居るのかな(笑)。逆に、その条件反対を入れたが為にbugになってしまった可能性もあるんじゃ無いだろうか。

例えば、新幹線チケットを購入するアプリならば、利用日として日付けデータが必要だけれど、そう言う所謂アプリケーションと呼ばれる一番上位のエンドユーザーの目に触れるソフトよりも、もっと下位の例えばパソコンのBIOSだとかファームウェアと呼ばれるハードウェアの中に埋め込まれているコードの方が、利用頻度というか影響度は高いと思うので、もしかした使用していたシステム(ハードウェア)の問題で、今回のうるう年問題が発生していた事例も多いかもしれない。どこに何がコーディングされているのかなんて、本当一度システムを組んでしまうと分からなくなりますからね。まぁ、今回問題が発生してアプリ出されたところは、次の2028年には問題無いのかもしれないけれど、その間に開発して利用開始されたシステムが、今度はまたトラブルを生むかもしれない。そういうイタチごっこというのが、ある意味永遠に続くのがソフトの世界と言えるのかも。