サマータイム導入に関するシステムへの影響
驚愕の自民党議員
通勤時にある記事を読んでいて、驚愕しました。
その際はこれまで指摘されてきたいくつかのデメリットを、一つひとつ丁寧に解決し ていかなければならない。長時間労働に対しては、既に動き始めた働き方改革により、 かなりの歯止めが期待される。 コンピュータなどの時間設定の変更は、律儀で真 面目な国民ならば十分乗り切れるはずだ。 余暇時間の過ごし方が、エネルギー消費の 削減につながるような工夫も必要だ。一方、睡眠不足などによる健康障害問題は、むしろ 個人の心構えにより、多くは解消されるはずだ。
自民党 船田はじめ 議員 "はじめのマイオピニオン - my opinion -"
「 マータイム制度の導入について 」 より引用 [1]
最初の印象は、「何、言ってんだ、こいつ？」 国会議員としては、あまりに無責任過ぎると思います。
サマータイムについては個人的にはニュートラルで どちらもでよいです。ただ、制度実施に必要なコストとか度外視して精神論で 「なんとかなるさ」というアホな政治家もいるのであれば心配になってきました。
前回 は感情的に書いてしまったので コンピューターシステムにどんな課題があるかまとめておこうと思います。 ここではサマータイムの是非については一旦棚上げします。
ITの世界では米国の言葉の方が一般的なので、ここではサーマータイムを 「デイライト・セイビング・タイム(以降、DSTと略記)」と呼びます。
多くのコンピューター自体の対応は大きな問題ではない
実は多くのコンピューターでは、WindowsであれLinuxであれ、Androidであれ 仕組みとしては対応済みなのです。
今日のコンピューターは世界中の至る所で使用され、なおかつネットを通じて世界 と繋がっています。こんな状況でそれぞれのコンピューターがそれぞれ現地時間で 稼働していてはいろんな不具合が出ます。
そのため、多くのコンピューターは内部的には 協定世界時 (以降、 UTC と略記) で時間を管理しています。しかし、それでは人間には分かりにくいので、「地域」の設定 従ってUTCを現地時間(以降、Local Timeと略記 )に変換して表示する仕組みを持っています。このような仕組みを 「国際化対応 (Internationalization, I18N)」と言います。具体的には「タイムゾーン」 と呼ばれる同じ時間帯を使っている地域情報と UTCからの時差で管理されています。
この「タイムゾーン」という仕組みは世界中で使われているので、DSTも当然考慮 されています。「日本はいつからいつまでがDSTである」という定義がなされれば システムとしてはそのまま対応できます。
このような各地域のタイムゾーンに関する情報は、 Internet Assigned Numbers Authority(IANA) で収集されデータベース化されています。このデータベースは tzdata と呼ばれ Unix系のシステムであればシステムの一部として収められています。
コンピュータ自体の対応は、このtzdataを更新することで対応可能です。
ただ、これはコンピューター自体が DSTに移行した日本時間を扱えるというだけです。 ここで言う「コンピューター」とは WindowsやAndroidなどの オペレーティング・システム(以降、OSと略記) やデータベースシステムなどです。
企業のコンピューターは、これらOSの上にビジネスを支えている 業務システム(アプリケーション・システム、以降アプリケーションと略記)が稼働しています。 「システムがDSTで問題があるか」という問題は、OSレベルだけでなく アプリケーションまでが正常に稼働して、はじめて「問題ない」と言えるのです。
従って、OSでの対応が上記のように可能であるとしても以下の2点の対応が必要です。
OSなどの変更により、アプリケーションに影響がないかというテストが必要
仕組みとしてDST対応しているOSと違い、DSTを考慮していないアプリケーション自体がDST対応する必要がある。
アプリケーション・システムに関するサマータイムの問題
アプリケーションでも当然「時間」や「時刻」を扱います。 例えば、「毎朝4時にバッチを実行する」とか「出退時間から勤務時間を計算する」などです。
では、DSTを考慮しない日本のアプリケーションでは、 DSTによりどういう問題が引き起こされるでしょうか？
こんな例を考えてみましょう。
時間Aに24時間を足して時間Bを算出している処理があったとしましょう。 この処理の意味は二通り考えられます。
24時間後の時間を算出したい
翌日の同一時刻を算出したい
1.を意図する処理であればDSTであっても何の問題もありません。むしろ変更してはいけません。
2.を意図して処理されているのであれば、DSTを挟んだ日では時間がずれてしまい想定と 違う時間を指すことになりますから不具合が発生します。当然修正が必要です。
これらは非常に単純な例ですが、DST適用で起こる問題とはこのようなものです。
日本のエンジニアは長らくDSTが日本に適用される想定などなしに一日は24時間である 想定でプログラムを設計してきました。DSTが適用されてきた国では上記のような処理 は1.と2.の処理は必ず違うロジックでコーディングされます。 日本ではDSTを意識していないので、問題のあるコードが書かれている可能性があります。
上記の処理の意図はプログラムだけを見ても分かりません。 その意図を確認するには、プログラムの設計書や要件定義書まで遡って処理内容を 確認する必要があります。DSTの影響がありそうな箇所を洗い出して、それぞれの設 計意図をドキュメントをひっくり返して「見極め」を行って、はじめて影響の有無が特定でき修正を開 始できるのです。
DST対応は他の国でも出来ておりOSも対応していますから実は大変ではないのです。この 影響箇所の「見極め」とその「見極め」が正しいことを検証するテストが大変なのです。
"may"と"must"の区別が付いていない中学生が書いた英語の小説を日本語のプロットを もとに校正する困難さとでも言えば、近いでしょうか？
IT関連のエンジニアが「とんでもない！ 間に合わない」という声を上げているのは上記 のような事情です。
アメリカの事例ですが、2007年にDSTの期間の変更が行われました。 "Energy Policy Act of 2005" というエネルギー政策の一環だったようで、適用まで 2年の猶予が与えられました。 大きな障害は聞こえてきませんでしたが、それでも上場企業だけで3.5億ドル (約400億円)の費用を投入され、「Mini Y2K」と呼ばれるほどIT業界は大変な騒 ぎだったようです。
以前からDSTを運用してきたアメリカで適用期間変更のみの対応で、しかも2年の猶予が あってすら混乱したのです 。
DSTを適用していない日本で、アメリカでのDST変更を上回る規模の対応を 律義さと真面目さで乗り切れると考えることができる脳みそは一体どんな構造をして いるのでしょうか？
まぁ、そもそも「IT革命」を「イットかくめい」と呼び、あのマイケル・ジャクソンに影響し 「This Is It」を作らせてしまった本物のアホが言い出しっぺなのだから、 それに乗っかってる政治家のレベルも押して知るべしでしゅうか。
(おまけ)コンピューターはどうやって時間を把握しているか？
ついでに、コンピューターがどのように時間を把握するかを確認しましょう。
コンピューターのOSの管理する時間を 「システムクロック」と言いますが、システムクロックは電源を落とすと 一旦時間が失われます。
しかし、それでは困るのでシステムの電源から独立したバッテリーなどで稼働し つづけるリアルタイムクロック(以降、RTCと略記)という機構を持っています。 「ハードウェア・クロック」と呼ばれることもあります。
OSは起動時にRTCから時刻を読み取り、システムクロックとして初期化し、 以降は自身で電源がオフになるまで時間を刻んでいきます。 現代では、NTPサーバーなどネット経由でより正確な時間が提供される環境があり、 定期的にこれらのサーバーに時間を問い合せ時刻修正する仕組みを多くのOSが もっており必要性は低くなっていますが。
「タイムゾーン」について書きましたが、RTCはタイムゾーンなど持っていません。 従って、OSは起動の際に読み取ったRTCの時間がUTCなのかLocal Timeなのかを 知らなければ正しいシステムクロックを設定できません。そのため、Unix系のOS ではRTCのタイムゾーンとシステムのタイムゾーンを両方管理しています。RTCの タイムゾーンでは、RTCのタイムゾーンを見ればRTCに時間がUTCかLocal Timeかわかる と言うわけです。
起動時はRTCのタイムゾーンを考慮しRTCからUTC時刻をシステムクロックにセットします。 OSは適時タイムゾーンを考慮してRTCの時間を書き換えます。 これはNTPなどより正確な時刻サービスがあるためですね。そうしてコンピューターは 全体としていつも正しい時間を維持できる仕組みになっています。
これは行儀のよいOSの例で、WindowsなどはRTCの時間はLocal Timeであると決め打ちして いるようです。
さて、 ここでもDST問題が見えてきましたね。
日本で稼働している多くのパソコンがWindows機でしょう。これらのマシンのRTCには Local Timeがセットされているのは当然です。RTCには「タイムゾーン」という概念があ りませんから、当然 DSTも考慮されていません。
つまり、 DST切り替えの際には時間が一斉に2時間狂います 。
とはいえ、Windowsの場合NTPとの時間同期は週に一回程度の間隔で行うようになっています。 1週間経てば補正されます。が、最長1週間パソコンの時間はずれたままです。
アプリケーションの問題ほど大きくありませんが。
結論
DST自体の対応は可能です。 ただし、数百億のコストと2年以上の時間が必要です。
銀行のシステムのように社会基盤となっているシステムもありますから 十分な影響調査とテストが必要ですが、その困難さは上記で上げた通りです。 そのためのコストと時間が必要で、2019年からの適用など不可能でしょう。
一般的なシステムについて述べましたが、同じような問題は電波時計や カーナビ、エアコン、炊飯器など時計を持っている多くの機器でも同様の問題は起こる 可能性はあります。そして、これらの売り切りのハードウェアはシステム変更が事実上 できないものもたくさんあります。
サマータイムのメリットはあるのだと思いますが、ここまでの労力を払って得られるものと バランスできるものなのか非常に疑問です。
まして、2年間の時限対応とかアホとしか。。。。
脚注