サマータイムに反対だと言っておきたい(後編)

ITの面から見たサマータイムはどうでしょうか。

法案では毎年3月の最終日曜日に時計の針を1時間早めて、10月の最終日曜日に元へ戻すことが検討されています。時計を変更する時刻は深夜1時か2時になりそうです。当然ですが、パソコンなどIT機器の時計も変更が必要です。

前回サマータイムを日本で実施したのは約60年前で、コンビニやファミレスが登場する前の話です。夜中に営業している店はほとんどありませんでした。夜中に動いているコンピュータシステムもほとんどない時代でした。しかし現代の深夜は、ITシステムのバックアップや夜間バッチ処理の時間です。企業によっては、なんとかギリギリで翌朝の営業開始に間に合わせている所もあると思います。サマータイム開始・終了の日は特別の対応が必要になって、システム管理者の方は泊まり込みになるでしょう。

サマータイムのITシステムでの実装方法は、システム内部にサマータイムに影響されない内部時計を持ち、利用するアプリケーションやユーザの属性としてタイムゾーンを別に持つのが理想的です。

パソコンやPCサーバーはハードウェアで内部時計を持っています。WindowsなどOS側では内部時計の時刻を元に各タイムゾーンに合わせた時刻を管理しています。(Windows XP以降では標準機能でNTPがサポートされて、内部時計に依存せずに時刻の自動合わせができるようになりました。)

Windowsで「太平洋標準時 (米国およびカナダ)」などを選ぶと、「自動的に夏時間の調整をする」チェックボックスが表示されます。ここをチェックしておくと、サマータイムの開始と終了で自動的に時刻を変更してくれるわけです。以前からサマータイムが普及している米国でさえ、2007年のように3週間前倒しで3月11日からの実施に変更された時はWindowsのアップデートが必要だったようです。

現時点の日本語版Windowsには「日本時間(GMT+09:00 大阪、札幌、東京)」にサマータイムを設定する機能がありません。本当に実施されることになればマイクロソフトからアップデートが提供されるはずですが、もしもアップデートが提供されなければ、日曜深夜にIT管理者が手作業で変更しなければいけなくなります。アップデートが提供された場合でも、インストールや確認の作業がパソコンとPCサーバーの台数分だけ発生するわけで、余計な手間です。

Windowsレベルの時刻変更をクリアしたとしても、アプリケーションレベルの問題の方が大きいです。

海外生まれのアプリケーションでは、システム内部のメインのタイムゾーンとユーザ毎のタイムゾーンの2つを持つのが普通です。ユーザが入力した時刻は内部時刻に変換して保存し、表示する時はユーザのタイムゾーンに変換して表示します。この方法ではサマータイムは見た目だけの問題で影響は少ないです。詳しい方がいましたら教えていただきたいのですが、私の知る限り、日本の個別開発の業務アプリケーションできちんとタイムゾーンを意識しているシステムはほとんどないのではと思います。

例えば、深夜は携帯を使ったオンラインショッピングのピークです。ショッピングカートに入れておいた商品が、切り替え時刻をはさんでタイムアウトと判断されて、カートから消えてしまうかもしれません。購入時刻を基準にしたバッチ処理で、代金を二重に請求してしまったり請求せずにスキップしてしまったりする事は起きないでしょうか。心配です。

時計を進めてまた戻すということは、同じ時刻が2度存在するということになります。場合によっては、2000年問題より深刻なトラブルになる可能性があります。しかも、法案が通れば来年の春から実施になるでしょうから、2000年問題の時と違ってITシステムの変更やテストの時間がありません。これで何か起きれば、建築基準法の改正や携帯サイトの未成年者に対する閲覧制限に続く官製不況になりかねません。

「国はわざわざ余計なことはしないで欲しい」というのが私の意見です。

皆様のITシステムのサマータイム対応は大丈夫でしょうか。