それではコンピュータシステムについて。

コンピュータ（システムやプログラム）には「時間経過」の概念がありません。命令を受けた瞬間からの経過時間は、秒単位でカウントアップしていくだけで、つまり「その瞬間」しかコンピュータは認識していません。

もう少し、かみ砕くと、「いま何時？ 3時か、あと2時間仕事しなければ」という発想はなく、命令された時間だけ作業を繰り返しているということです。

これをプログラミングにより擬似的に、時間経過の概念があるように見せかけているのが、エアコンなどの「タイマー機能」です。

反対に「時間の経過」を確認するプログラミングをすると、秒単位でカウントアップしていく内部時間とは別の、外部時間（時計）を用意しておかなければならず、さらに両者を絶えず確認しなければならないので、二度手間三度手間になってしまいます。

だから、どこかの瞬間、サマータイムにより2時間ないし、何時間と時間がずれても、そのまま処理するだけで影響は軽微です。目覚まし時計の時間がずれたら直すように「サマータイム」となったとき、コンピュータの時計を合わせ直せば良いだけのことです。

ホストコンピュータなどと接続していて、連続した情報をやりとりしているシステムなら、バチっと電源を落として、その後の立ち上げで日時の変更をすればよいだけのこと。

コンピュータに詳しくない人は、人間の意識する「時間」、便宜上「自然時間」と呼ぶとすれば、これを基準にコンピュータのことを考えます。

サマータイムとなり自然時間の定義が変われば、コンピュータも同時に変えなければと「思いこみ」ますが、コンピュータが処理に用いているのは、埋め込まれたクォーツが刻む「内部時間」だけです。

日時の処理は、内部時間を変換して行っているに過ぎず、自然時間の概念をコンピュータは必要としません。

なお、日時の変更はすべてのコンピュータシステムでできます。仮にできないコンピュータがあれば欠陥品と断言できます。なぜなら、内部時間を刻むクォーツには誤差があり、これを絶えず修正しなければなりません。

最新のシステムではネットを介した日時の自動修正や、電波時計を用いた萬年単位で狂いのないシステムを構築することもできますが、それでも、日付またぎ、年またぎ、うるう日のチェックなどのために、「日付を設定する機能」というのは必ず必要となるからです。

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。

なお、西暦の下二桁が0になる年にうるう日はありません。一方、400で割り切れる年はうるう日になります。つまり、2000年2月29日は、400年に1回訪れるうるう日でしたが、その400年に1回に対応するように、私が従事ししていたコンビニのPOSシステムは設計されていました。たしか昭和の終わり頃には。

つまり、日時変更できないコンピュータは、これらの処理を確認していない欠陥品だということです。

サマータイムは日付変更すればすむ話し。一方で24時間、365日絶えず稼働しなければならないコンピュータで、日付を変更するわずかな時間すら許されない場合はどうするか。

先のコンビニのPOSシステムでさえ、サマータイムにはいつでも対応できるように設計されていました。平成元年の時点なので、いまから30年近く前のことです。海外の事例を参考に、変更開始日時と、その変更時間の幅と、終了時刻を処理する仕組みが考えられていたのです。実際に店舗に配備されたレジに、その機能は搭載していませんでしたが、ゴーサインがあれば、瞬時に対応できるようにしていたのです。

プログラミングとは、その時点において考え得るすべてを洗い出し、対応できることは対応し、将来、予想されることに備えておくものです。

余談にそれますが、小学生からのプログラミング教育が無駄だというのは、実戦においてはプログラミング言語よりも、こうした常識と知識を踏まえて、可能性をさぐる論理力が求められるからです。

話を戻せば、浮かんでは消え、なんども議論されている、サマータイムへの対応、あるいは準備をしていないコンピュータ・システムの業者がいるなら、静かに退場すべきであり、裏返せば、多くのシステム屋はある程度の備えをしているものだということです。

なにより、今の時点からでも即座に対応できる程度のことです。2018年8月8日の読売新聞は「元号の変更とあわせてシステム改修が間に合わない」と書いていましたが、あまりにも無知。

コンピュータの内部は西暦で処理されていますが、元号表記が必要な場合、「1989年1月8日からは平成」と変換しているだけのことです。それが次は「2019年5月1日からは○○」と新元号の処理を一行加えるだけです。

さらにこれらの制御は「フラグ」によって行います。あるフラグが立っていれば元号処理、または「新元号」を含んだ処理をさせ、そうでなければ通常処理という具合です。

サマータイムも同じく、「サマータイム」のフラグが立っていれば、サマータイムの開始日時を参照し、その切り換え日ならば、必要な時間調整をするというだけのもの。プログラミング初心者でもできる程度の処理です。

一方で、ここがサマータイム導入が日本で難しいところに直結します。この記事を書いた読売新聞の記者のように、コンピュータへの無理解と、同時にコンピュータへの過大な期待が、日本社会にはあるからです。

先に述べたように、時間のずれた目覚まし時計を合わせるように「日付時刻の変更」をすれば済むだけの話。仮に政府案のとおり、東京五輪までの2年間限定ならば、システム改修など不要で、サマータイム開始日と終了日の年2回×2年の4回だけ「人力対応」すれば済む話。

これは「費用対効果」の話しです。システム改修に数千万円も掛けるなら、そこだけ「手間」をかけるほうが安上がりで合理的なのですが、こう考える日本人は少なくありません。

「コンピュータに任せているのだからコンピュータにやらせるべきだ」と、「自動処理」を望む日本人が少なくありません。筋が通っているようですが実は珍説。コンピューターは道具に過ぎず、それをつかって人間がどう楽するかがポイントなのに、コンピュータだけで完結させるために人間が右往左往するのです。

また、サマータイムの変動幅が2時間とすると、初日の一日は22時間となり、終了日は26時間となります。この時の売り上げの扱いはどうするのか、また「日給」はどうするのか、そしてこの処理をコンピュータにさせるにはどうすべきか、とまぁ馬鹿馬鹿しい議論が、プログラミングの前に行われます。

これを「仕様」と呼ぶのですが、主に発注者の「希望」が盛り込まれるもので、この発注者がコンピュータを理解していないことが多く、無理難題が盛り込まれることも多々アリ、これが日本のIT化を遠ざけている大きな要因となっています。

イレギュラーはイレギュラーとしてあきらめるのもプログラミングにおける基本なのですが、無知な人ほどコンピュータに「完璧」を求め、完璧を求める日本人の性向がこれに拍車を掛け自体を悪化させます。

その完璧さを求める性向が、ひとつの不備を見つけると全体に当てはめ、そして「サマータイムにシステム改修が間に合わない」という暴論を新聞が拡散し、みなが根拠無く同意し、先送りされてきた。これが「平成サマータイム議論」です。

こうした日本人の性向、習性からサマータイムは難しいのですが、反面、本来的な日本人が兼ね備えている「不便を楽しむ」ことができればサマータイムなど難なく乗り切れることでしょう。

つまり、アスリートファーストなどの詭弁では無く「不便なのは開始と終了の二日だけ。あとは慣れようよ」と、開き直ったアナウンスを政府がしてしまえば、勤勉でいてイベント好きな日本人なら、勝手に盛り上げてアジャストすることでしょう。

さらに、月替わりではなく「週末」や、やたらと増えた「三連休」をサマータイムの切り換え日に当てれば、寝不足や時間調整のイベント化だってできます。

image by: Shutterstock.com