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

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

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

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

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

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

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

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

参考「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年問題であれだけ騒いで何も起きなかったという噂もあるので、実は大した事はないという意見もありそうです。

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

最近のエントリ

• Interop 2023のShowNetバックボーン詳解
• Interop Tokyo 2023 ShowNet取材動画
• 「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました！
• 1.02Tbpsの対外線！400GbE相互接続も - Interop ShowNet 2022
• Alaxala AX-3D-ViewerとAX-Sensor - Interop 2022
• SRv6を活用し、リンクローカルIPv6アドレスだけでバックボーンのルーティング - Interop ShowNet 2022

過去記事

過去記事一覧