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

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

カレンダーソフトに見るアメリカの夏時間処理の違い

»

昨年からのアメリカの夏時間 (DST: Daylight Saving Time) のルールの変更によって、夏時間が終わるのは、11月の第1日曜日の午前2時になった。今年だと11月2日(日)がその日にあたる。ちょっと興味があったので、各種カレンダーソフトがこの時間の処理をどのようにやっているのかを調べてみた。日本のカレンダーソフトは、そもそも夏時間や時差の概念がないので全滅である。調べたのは、業務に使っている、Lotus Notes, Microsoft Exchange (Outlook client), Google Calendar である。

結果は、「どれも完全にはできていない。」という評価になった。操作による違いや設定の方法で違う結果が出るかもしれないが、実際に使っている状況なので、かなり確実な結果だと思う。


Dstnotes_6

画像1: Lotus Notes

Dstoutlook
画像2: Microsoft Outlook

Dstgoogle
画像3: Google Calendar

 

 上の画像で、Tokyo と書かれているカラムは、日本時間、Bellevue と書かれているカラムは、アメリカの西海岸の時間 (Pacific Time) を表示している (Outlook だけ左右逆になっている)。赤色で囲んだ東京時間の 8pm に注目して欲しい。これはアメリカの西海岸の時間では11月2日(日)の早朝で、すでに冬時間に変わった後なので、Bellevue のカラムでは、3am となっているのが正しい。しかし、Outlook だけは、4時という間違った時間を表示している。その意味では、Lotus Notes と Google Calendar の方が良い。次に画像1の Lotus Notes の Bellevue のカラムの一番上を見ると 12am が2回きている。これは、正しい処理をしようとしているけれどもルールでは重複するのは 12am でなくて 1am であるので、おしいという感じの処理である。画像3の Google Calendar は、処理を簡素化しているのか、その日の最初から冬時間を開始している。Google Calendar について付け加えると、11月1日から「次の日」に移動することで11月2日を表示している場合、間違った夏時間表示のままであったが、画面をリフレッシュしたら上記の画像3の「ほぼ正しい表示」になった。

時間の変わるのが日曜日の早朝なので、この違いが大きな問題を引き起こすことはないであろう。人間には結構わかりやすいルール(11月の第1日曜日の午前2時に、時計を1時間戻して午前1時にしなさい)をコンピュータで実現しようとすると非常に大変なことになるという、非常に良い例である。

最近少し下火になったかもしれないが、日本政府にも夏時間制度を採用しようという動きがあった。夏は朝早くからやけに明るい日本の東側に住んでいると、個人的には夏時間採用には賛成であるが、夏時間など全く考えていないソフトウェアを夏時間に対応させる必要が出てくる。そしてそれによって、おそらく2000年問題以上の莫大なコストがかかることになる。それを考えると、日本での夏時間制度の採用の可能性はほとんどないと思う。

Comment(2)