| « 2008年10月30日 | 2008年10月31日の投稿 |
2008年12月2日 » |
昨年からのアメリカの夏時間 (DST: Daylight Saving Time) のルールの変更によって、夏時間が終わるのは、１１月の第１日曜日の午前２時になった。今年だと１１月２日（日）がその日にあたる。ちょっと興味があったので、各種カレンダーソフトがこの時間の処理をどのようにやっているのかを調べてみた。日本のカレンダーソフトは、そもそも夏時間や時差の概念がないので全滅である。調べたのは、業務に使っている、Lotus Notes, Microsoft Exchange (Outlook client), Google Calendar である。
結果は、「どれも完全にはできていない。」という評価になった。操作による違いや設定の方法で違う結果が出るかもしれないが、実際に使っている状況なので、かなり確実な結果だと思う。
画像１： Lotus Notes
画像２： Microsoft Outlook
画像３： Google Calendar
上の画像で、Tokyo と書かれているカラムは、日本時間、Bellevue と書かれているカラムは、アメリカの西海岸の時間 (Pacific Time) を表示している (Outlook だけ左右逆になっている)。赤色で囲んだ東京時間の 8pm に注目して欲しい。これはアメリカの西海岸の時間では１１月２日（日）の早朝で、すでに冬時間に変わった後なので、Bellevue のカラムでは、3am となっているのが正しい。しかし、Outlook だけは、４時という間違った時間を表示している。その意味では、Lotus Notes と Google Calendar の方が良い。次に画像１の Lotus Notes の Bellevue のカラムの一番上を見ると 12am が２回きている。これは、正しい処理をしようとしているけれどもルールでは重複するのは 12am でなくて 1am であるので、おしいという感じの処理である。画像３の Google Calendar は、処理を簡素化しているのか、その日の最初から冬時間を開始している。Google Calendar について付け加えると、１１月１日から「次の日」に移動することで１１月２日を表示している場合、間違った夏時間表示のままであったが、画面をリフレッシュしたら上記の画像３の「ほぼ正しい表示」になった。
時間の変わるのが日曜日の早朝なので、この違いが大きな問題を引き起こすことはないであろう。人間には結構わかりやすいルール（１１月の第１日曜日の午前２時に、時計を１時間戻して午前１時にしなさい）をコンピュータで実現しようとすると非常に大変なことになるという、非常に良い例である。
最近少し下火になったかもしれないが、日本政府にも夏時間制度を採用しようという動きがあった。夏は朝早くからやけに明るい日本の東側に住んでいると、個人的には夏時間採用には賛成であるが、夏時間など全く考えていないソフトウェアを夏時間に対応させる必要が出てくる。そしてそれによって、おそらく２０００年問題以上の莫大なコストがかかることになる。それを考えると、日本での夏時間制度の採用の可能性はほとんどないと思う。
| « 2008年10月30日 | 2008年10月31日の投稿 |
2008年12月2日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命