「サマータイム？　2000年問題のときと同じでしょ」は大間違い

「熱」は冷めつつあるが…

自民党総裁選の陰で、2019年からのサマータイム（夏時間）導入の検討が進んでいる。東京オリンピック／パラリンピック（オリパラ）の省エネと暑さ対策を目的に、2019・2020年の2年に限って、6月から8月末までの3か月間、時計の針を2時間早めるという。ついに自民党はサマータイム検討議連なるものも立ち上げるという。

しかし、夏の酷暑が過ぎ去るとともに、世の中のサマータイム熱も下がりつつあるようだ。

当初は、「会社勤めの人は明るいうちに帰れる」「一家団欒の時間を作れる」といったメリットも喧伝されていた。それに対して「寝不足による事故やトラブルが増える」「残業が増える」「節電・省エネの効果がない」「システムの改修が間に合わない」といった異論反論が吹き出てきたのは周知の通りだ。

結論がどうなるかは先の話だが、本稿ではサマータイムが実行された場合、IT業界が強いられる対応の過酷さについて話しておきたい。

思い出す「2000年問題」の混乱

サマータイムの議論で焦点となっているのが、コンピュータ・システムの時刻管理の問題である。これに関連して、よく引き合いに出されるのが、約20年前に日本中が大騒ぎになった「2000年（Y2K）問題」だ。

1950年以後に開発され発展してきたコンピュータは、西暦を下2けたで管理するように設計されていた。メモリーがものすごく高価だったため、使用する記憶領域を最小限に抑える工夫だった。

ところが西暦2000年になると、西暦表記が２けたのままでは2000年が「00」、2001年が「01」となってしまい、例えば「（19）50年生まれの人よりも（20）01年生まれの人のほうが高齢だ」とコンピュータは判断する。なぜなら下2けたでソート（並べ替え）するからだ。

そうすると、生まれたばかりの赤ちゃんに高齢者福祉の通知が届くことになりかねない。また、定期預金の口座開設日時に「00年」と表示されると、とうの昔に満期を超過していると判断されて口座が作れない、あるいはコンピュータが勝手に100年分の利子を付けてしまう、といった問題も発生する。