サマータイム法がIT業界に与えるかも知れない衝撃

2008/6/5-2

サマータイムが導入が検討されているようです「Asahi.com : サマータイム法案、今秋成立めざす」。

実はこの法案はIT屋さんにとって結構な大事なのではないかと思い始めました。 そこら中のソフトウェアを大規模に再検証してまわらなければならないかも知れません。

サマータイムへの切り替えを行うという前提で設計されていないソフトウェアは世の中にどれだけあるのでしょうか? 既に稼動している公共システムに入っているソフトウェアやハードウェアの検証項目にサマータイム制は入っていたのでしょうか? サマータイムへ切り替える方法って家電機器に導入されているんでしょうか(新しいテレビにはあった気がします)?

あと、高速ETCの時間割引や各種交通制御システムや、銀行ATMの稼動時間制御や、時間帯別手数料や、スケジューラ、ログ解析ソフト、工場内部で利用されているソフトウェア、etc...検証し直さなければいけないシステムは結構ありそうですね。 内部がUTCならばOKですが、JSTに変換した後に何かを比較したり+9前提とかしていたら厄介ですね。 課金が絡む系統の物とサマータイムは非常に相性が悪そうです。

システムとは関係ありませんが、細かいところでは辞書や辞典の記載も変更が必要そうですね。

サマータイムの実施日が変更された影響例

アメリカでは、2007年にサマータイムの実施時期が変更されたそうです。 そのときの変更のために、Windows Updateが必要になったようです。 以下、マイクロソフト社のサポートページから一部引用です。

2005 年 7 月、米国議会は夏時間 (Daylight Saving Time : 以下、DST) の開始日と終了日を変更する 「2005 年エネルギー政策法」 を通過させました。これにより約 4 週間、DST が延長されました。この法案により、DST は従来より 3 週間早い 2007 年 3 月 11 日に始まり、1 週間遅い 11 月 4 日 に終了することになります。このため DST はこれまでより 4 週間延長されます。

参考「microsoft : 2007 年の夏時間変更のための準備」DST変更の影響を受けるマイクロソフト製品が列挙してあります。

Unixの場合

Unixは内部でUTC(協定世界時)使っているので、timezoneのDST(Daylight Saving Time)フラグを立てればOKですが、 何も考えずにGMT+9をGMT+10にしてしまうオペレータが出現すると何かが発生してしまうかも知れませんね。

ただ、DSTに切り替わったり、元に戻ったりする日は国によって違うのですが、その変更ってどうやってトリガーしてるんですかね?



 struct timezone {
   int     tz_minuteswest; /* of Greenwich */
   int     tz_dsttime;     /* type of dst correction to apply */
 };



最後に

なお「サマータイムやめましょう」と言っているのではないのでご注意下さい。 「うわ!大変そう。。。」と思った今日この頃です。

2000年問題であれだけ騒いで何も起きなかったという噂もあるので、実は大した事はないという意見もありそうです。

業界によっては実は検証特需になるという考え方もあるので、立場によって色々違いそうな気もします。。。

プロフェッショナルIPv6解説動画シリーズ再生リスト

動画で学ぶ「プロフェッショナルIPv6」を作っています。 もしよろしければご覧ください。お楽しみいただければ幸いです!