元々、日時は、様々な罠がある複雑な処理

　さて、IT業界の人が、不満の声を上げたのは、元号の変更だけではない。サマータイムの導入の話が出た時も猛反発したのを覚えている方もいるだろう。普段、プログラムを書かない人は「数字のことだけではないか」と思うかもしれない。でも、プログラマーは、なぜ嫌なのか想像がつくはずだ。日時に関する処理は、プログラムの中でも、けっこう面倒くさい部類に入るのだ。 　コンピュータは、日本語で書くと電子計算機となる。数字の計算が得意だ。計算には、足し算や引き算、掛け算や割り算などがある。少し計算をしてみよう。1＋1は2。123＋123は246。簡単だろう。では、12月23日＋2ヶ月31日はどうだろうか？　簡単にできるだろうか？ 　そもそも「2ヶ月31日を足す」とは、どういうことだろうか？　12月から2ヶ月進めて、23日に31日を足すことか？　あるいは1ヶ月を30日として考え、2ヶ月で60日、そこに31日を加えた91日を足すことか？ 　どちらにしろ、12月から数ヶ月進めると翌年になる。さらに、2月の日数は、閏年かどうかで変わってくる。この計算をするには、今が何年かによって計算結果が変わるわけだ。 　それに、そもそも12月23日は、世界のどこにいた場合の「12月23日」なのだろうか？　日本で12月23日の時に、他の国では違う日かもしれない。「いやいや、日本のことだけを考えればいいだろう」とおっしゃるかもしれない。それなら、世界展開している企業ではどうだろうか？ 　さらに言うと、日付には閏秒もある。地球は、原子時計を基準にした1日よりも、約2ミリ秒（1ミリ秒=1/1000秒）ほど長くかかって1回転する。500日で1秒ずれるのだ（参照：「うるう秒」ってなに？ | 国立天文台（NAOJ））。 　このように、プログラムの日付計算は、実はかなり面倒くさい処理なのだ。そうした計算を代行してくれる、ライブラリやAPIというプログラムの部品もあるが、その内容も、年を追う毎に徐々に改良されてきたものだ。10年、20年前の処理と、今の処理が同じ保証はない。30年前、40年前となると、それぞれのプログラムで、独自の計算をしている可能性もあるのだ。 　古いプログラムの計算結果が、今の基準で正しい保証はどこにもない。現在稼働している古いシステムは、その都度、問題を局所的に解決する処理を加えて、建て増しを続けた状態になっている場合もある。 　そうした複雑怪奇な部分に手を付けることは、秘境に探検に行くような難しさがあるのだ。動いている機械を止めたら動かなくなった。そうしたことにならないためには、入念な準備と、綿密なテストが必要なわけである。