オルタナティブ・ブログ > Software Development >

ソフトウェア製品開発現場の視点

コンピュータによる「夏時間」の扱い方についての解説

»

前回のブログで、コンピュータソフトの問題で日本で「夏時間」を採用するのは難しいということを書いたところ、わかりにくいという指摘を受けました。確かに説明不足でしたので、すこし詳しく解説してみます。

現在の多くのコンピュータは、内部に時計を持っています。厳密に言うと複雑になるのですが、説明上、Windows や Mac OS などが時間を知っていると思ってください。たとえば、Windows では、一番右下に時刻が表示されており、その時刻をクリックするとカレンダーが出てきます。

Clock

私の Windows の設定の事情で、月や曜日が英語で表示されていますが、通常は日本語で表示されます。このときに、1:05:49AM と表示されているのは、日本の時刻です。

もし、このコンピュータを持ってカリフォルニアに行って、時刻を表示したらどうなるでしょうか? 何の設定変更もしなければ、このコンピュータは「日本時間」での時刻を表示し続けます。短期間の滞在なら、まあ読み替えて使えばいいかもしれませんが、カリフォルニアの時間に合わせたほうが便利です。

日本とは時差がある場所に行ったときの設定変更は、「コントロールパネル」⇒「時計、言語および地域」⇒「日付と時刻の設定」で行います。以下の画面を参照してください。

Dateandtime

この画面には、「日付と時刻の変更」と「タイムゾーンの変更」の2つのボタンがあります。上のボタンは、コンピュータの時計の時刻を変更するボタンです。しかし、カリフォルニアに行ったときには、このボタンではなく、「タイムゾーンの変更」ボタンで変更します。

なぜこのような複雑なことになっているかというと、コンピュータの時刻の持ち方に原因があります。コンピュータは、時刻を UTC (世界標準時) を持っています。しかしそのまま表示すると不便なので、指定したタイムゾーン分だけシフトして表示します。上の画面では、「時刻」に12:49:31 AM と表示されていますが、コンピュータ自体は、この時刻を UTC で前日3月30日の 3:49:31 PM であるという情報と、「大阪、札幌、東京」という場所は、UTC よりも9時間進んでいるという情報を持っています。そして、その結果として、12:49:31 AM が現在いる場所の時間が表示されているということです。上の「日付と時刻の変更」ボタンは、UTC の時刻自体を変更する機能です。カリフォルニアに自分が移動しても、UTC は変わらないので、「日付と時刻の変更」ボタンを使ってはいけません。

では、日本で夏時間が導入したらどうすればよいでしょうか? タイムゾーンは変わらないので、「タイムゾーンの変更」ボタンでもないでしょう。良く見ると「タイムゾーンの変更」ボタンの下に気になる記述があります。「このタイムゾーンでは夏時間は実施されていません」と書かれています。試しに、「タイムゾーンの変更」ボタンを押して、カリフォルニア時間に変えてみます。カリフォルニアは、「太平洋標準時 (米国およびカナダ)」ですので、これを選びます。

Pdt

OK を押すと、先ほどの「夏時間は実施されていません」という表示が、「夏時間は、Sunday, November 06, 2011 - 2:00 AMに終了します ...」という表示に変わりました。Windows は「夏時間」がいつ始まって、いつ終わるかのルールもすべて持っていて、夏時間と冬時間の間が入れ替わるときタイミングで、「表示される」時刻を勝手に変えてくれます。もし正式に日本で夏時間が採用されると、マイクロソフトの定期アップデートによって、Windows に日本の夏時間がルールが入って、そのルールに従って時刻が表示されることになります。重要なのは、UTC は地球上のどこに行っても、夏時間が採用されるされないに関わらず不変ということです。ここでは、Windows で説明しましたが、Mac OS, Linux, Unix などの OS でも時刻はほぼ同様に扱われています。

今回夏時間の採用で問題となる原因は、アプリケーションソフトウェアの作り方です。ソフトウェアの多くは中で時刻を扱っています。日本では経験上、多くのプログラムはローカルタイム、すなわちその場所の現在の時刻を使っています。なぜなら、そのほうがプログラムを書くのが簡単だからです。そして、ほとんどの場合時刻が「前に戻る」というケースは考慮されていません。たとえば Suica は、改札を入った時刻と改札を出た時刻が記録しますが、改札を出た時刻が入った時刻よりも前だった場合の動作は、おそらく「不明」です。それは、日本のように時差もない、夏時間もない環境だと、そのような状況が想定されていないからです。Suica の例は、私の想像も含まれていますので、実際は問題がないかもしれませんが、時刻が「戻る」という場合でも正しく動作するかは一つ一つ検証が必要です。

国の中に時差があったり、夏時間をすでに採用している国や、世界中で使われているソフトウェアでは、プログラムの中の時刻は UTC が使われています。UTC を使えば、「時刻は前に戻らない」という前提でプログラムが作られていても、問題ありません。

Comment(8)