PR

謎5.閏年ではない1900年を閏年と見なす

【現象】 暦には実在しない「1900/2/29」が存在

⇒【解説】 閏年のルールを間違えた「ロータス1-2-3」の呪縛

 Excelは1900年以降の日付を管理する仕組みを備える。日付関数を用いて「毎月10日」などの請求日を計算したり、曜日を判定して「毎週水曜」を休業日としたりと、便利に活用している人は多いだろう。だが、その日付管理の機能に、バグ(不具合)があることをご存じだろうか。

 それは閏年にまつわるバグだ。そもそも閏年は、4年に1回必ず来るものではない。西暦年が400で割り切れる場合を除いて、100で割り切れる場合は閏年とならない(図1)。つまり、この例外に当てはまる1900年は閏年ではない。

図1 まず閏年のルールを確認しよう。4年に1度が基本だが、2つの例外がある。これにより、1900年は閏年ではなく、2000年は閏年だった

 ところが、Excelが日付を管理する「シリアル値」という仕組みの上で、1900年は閏年として扱われている(図2)。シリアル値は、1900年1月1日を1として、1900年1月2日が2、1900年1月3日が3という具合に、1日に1ずつ増える連番となっている。このシリアル値60に、1900年2月29日という実在しない日付が割り当てられているのだ(図3)。

図2 一方、Excelは1900年を閏年と見なす。日付を入力したセルをドラッグすると、連続した日付を自動入力できるが、この操作でも1900年2月29日という実在しない日付が入力されてしまう
図3 Excelは日付を「シリアル値」と呼ばれる連続した整数で管理している。シリアル値「1」に1900年1月1日を割り当て、2、3、4……とそれ以降の日付を1日ずつ割り当てた。このシリアル値「60」に、実在しないはずの1900年2月29日が割り当てられている

 実はこのバグ、Excelが普及する前に絶大な人気を誇った表計算ソフト「ロータス1-2-3」(以下、1-2-3)に由来する。1-2-3の開発者は、閏年は「4年に1回必ず来る」と誤解していて、1900年が閏年ではなかったことを知らなかったらしい。このバグは後になって認識されたが、修正すれば、作成済みのデータと整合性が保てず、混乱を招く恐れがあるとして、そのまま残されたという。

 そしてExcelも、このバグをそっくり継承した。なぜなら、当時大きなシェアを握っていた1-2-3を追撃するには、1-2-3との十分な互換性を実現し、データをスムーズに移行できることをアピールする必要があったからだ(図4)。シリアル値が1日分ずれてしまうことで生じる混乱と、1900年2月29日が存在することのデメリットを天秤にかけ、バグについても“互換性”を維持する選択をしたのである。

 ちなみにこのバグにより、1900年2月28日以前の曜日は、全て1つずつずれている。通常は問題になることは少ないが、注意したい点だ。

図4 マイクロソフトのサポート情報(英語)によると、1900年は閏年ではないが、1-2-3との互換性を重視して、誤った仕様をそのまま継承したという(左)。確かに、1-2-3でも同様に1900年2月29日が存在する(右、画面は1-2-3 2001)