コンピュータの時計とサマータイム、何が問題なのか?

オリンピックに関連してサマータイムの導入が話題になっている。導入されるかはわからないが、サマータイムのコンピュータシステムへの影響について整理しておきたい。

コンピュータの時刻の扱い方

サマータイムのコンピュータシステムへの影響について論じる前に、コンピュータでの時刻の取り扱い方について復習しておきたい。

ハードウェアクロック

コンピュータは、通常ハードウェアとして時計を保持しており、電源オフの状態でも内蔵の電池を使用して時刻を刻んでいる。通常は、ハードウェアクロックの時刻として、UNIXはUTC、Windowsはローカルタイムを使用している。

OSによる時刻の取得

コンピュータを立ち上げると、OSが起動する。OSは、起動時に時刻を保持しておらず、パソコンのハードウェアから時刻を取得して、OSのメモリ上に時刻をセットする。OSは、例えば1970年1月1日午前0時0分0秒からの秒数を時刻として保持する。

OS起動後の時刻補正

ハードウェアから取得した時刻は、電源オフ時にも時刻を刻んでいるとはいえ、時刻が少しずつずれていくため正確とはいえない。そのためパソコンの場合、OSが起動すると時刻同期サーバに時刻を問い合わせ、OSの時刻を修正する設定になっていることが多い。

ハードウェアクロックの時刻補正

OSの時刻同期が始まると、今度は逆に定期的にOSの時刻でハードウェアの時刻を修正する。ハードウェアの時刻はOSとは独立に動作しているため、次第にOSの時刻からずれていくためである。ハードウェアクロックをOSの時刻に合わせることで、次回OS起動時に発生する時刻のずれを少なくすることができる。

コンピュータにおける時刻の表示

OSが時刻を表示する際は、OSが保持しているタイムゾーンのデータベースを参照して時刻を出力する。タイムゾーンのデータベースの内容は、以下のようなものになる。

  • UTCからの時間の差分
  • サマータイムの開始年、終了年
  • サマータイムの毎年の開始日、開始時刻、終了日、終了時刻
  • サマータイムでずらす時間量

タイムゾーンのデータベースについて

タイムゾーンのデータベースは、各国でタイムゾーンの変更やサマータイムの実施が決まると、OSベンダーがパッチを提供する。つまり、各国政府がサマータイムの導入を決めた後、OSベンダーに妥当な時間が与えられれば、タイミングは図るとしてもパッチ適用によって時刻の表示については、時計の針を進めたり遅らせたりしなくても対応できてしまう。では、何が問題なのだろうか?

コンピュータシステムとサマータイム

コンピュータシステムは、基本的にOS上に、OSとは別に開発されたプログラムを稼働させている。サマータイムの切り替えを午前2時として、2時間時刻をすすめる場合を例に、サマータイムに対応していない日本のコンピュータシステムおいてどのような問題が発生しうるか挙げてみる。

時間の計算や時刻の前後の判断への影響

OSから時刻を取得した時に、サマータイムの判断を行わないと時刻の差分を取った時に値が不正となる。サマータイムに変更直後の4時からサマータイム前の1時の差分をとると3時間になるが、正しくは1時間である。また、時刻が戻る際には、時刻の前後の判定が正しくなくなる。例えば、サマータイムの3時とサマータイム終了後の3時を比較すると同じ時刻になってしまうが、正しくはサマータイム終了後の時刻が2時間遅い。

バッチ処理起動への影響

2時から4時の間に起動するバッチ処理があると処理がうまく動作しない可能性がある。サマータイム前の2時に到達するとサマータイムの4時になるが、例えば3時台に複数の処理を起動する予定になっていると、時間間隔を含めて順々に実行しないと処理が正常終了しない可能性がある。また、時間が戻る場合は、サマータイム時とサマータイム後の同じ時刻が2度訪れるので、処理が2度実行されないように、さらに目的とする方の時刻に起動させる必要がある。

サマータイムの導入にともなう業務やサービス提供内容の変更

2時間も時間を前後させることになると、特にサマータイム開始時に2時間も処理可能時間が短くなり、夜間に実施しているバッチ処理が翌日のサービス開始までに間に合わないケースが続出しそうである。そのような場合、例えばサマータイム開始日にはサービス開始時刻を遅らせたり、データの反映を翌日に回すなどの対応が必要になる。

システムの修正方法と修正期間

修正方法としては、OSから時刻を取得して処理する際に、サマータイムのフラグを見て処理を行うように修正する。時刻の順序性を重視する場合は、UTCを使用してサマータイムを反映しない時刻で処理をしたほうが良い場合がある。システム間連携を行う際は、時刻の形式をUTCで行うのかローカルタイムとサマータイムのフラグで表現するのかなどを調整する必要がある。修正期間の問題としては、サマータイムのフラグを見ていないと思われる大半の日本のプログラムを、例えば2年以内にすべて直すのは難しいと思われる。

総括

時刻の表示と、時刻を使用した処理への影響は分けて考える必要がある。時刻の前後関係を正しく判定できなかったり、処理時間として確保されている時間が短くなるとコンピュータシステムのみではなく社会に様々な影響や混乱が発生する。サマータイム導入にかかる負担、サマータイム運用(年2回の時刻変更に伴う社会ルールの複雑化、生活パターンの変更、仕事内容の変更)にかかる負担、サマータイムを再度変更したくなった場合の負担が発生することに注意する。メンテナンスに負荷がかかるICTが社会インフラ化し、バッチ処理などを含めてICTを24時間をフルに活用して業務やサービス提供を行うようになった時代においては、生活の基本となる時刻は変更せずに、個々の問題は個々に対応するほうが、サマータイムの導入より適した解決策になるかもしれない。

感想

サマータイムは、各国で導入実績があるが、廃止になったり廃止の議論が進められているケースが多いと聞く。日中の時間を有効に活用できるというのがメリットになるが、睡眠など人体に影響があったり、普及が進んだICTへの影響が大きいのがデメリットとされている。私も海外生活の経験がありサマータイムを経験しているが、まだ幼き頃でICTが発達していない時代であったため、「サマータイムは明日からだよね!」などと会話しながら時計の針を前日中に進めたりしていたことを思い出す。しかし、時代は変わってしまったようだ。今では、時計の針を勧めたり遅らしたりすることに大きな抵抗を感じるようになり、社会へのインパクトが大きいならば、本当に必要性が高くなければ避けるべきではないかと思う。