サマータイム導入で影響を(ほとんど)受けないITシステムは何だろう…Excelで済むような業務、弥生会計や勘定奉行による経理処理くらいであればあまり影響は受けないかな(条件にもよる)…そうだ、いいこと思いついた。全部Excelでやればいいのだ……ガキッ(背後から石が飛んできてぶつかった音)
— 徳丸 浩 (@ockeghem) August 12, 2018
この辺りの話。
今のOSではUTCが認識されている。ネットワークにつながっているものはNTPを用いているので、「時計を二時間進めて」という対応ではなく、「タイムゾーンを変更する」ようになる。
この辺り、「間違えないように周知する」必要がある。
また、タイムゾーンを追加するような処理が必要。日本標準時、はUTC+9を維持し、日本夏時間はUTC+11という形で作る。今あるタイムゾーンであればソロモン諸島あたりの時間を用いる事になる。
記録上は「ローカル時間」を用いる事が多い為、注意が必要。
ローカル時間、というと分かりづらいが、つまりは「タイムゾーンは記録されていない」事が多く、期間計算とかでも特にタイムゾーンを意識されていないので変更する必要が出てくる。
記録される時間は、タイムゾーンを切り替えつつ対応するというような必要はまずないというか、タチが悪いのでやめた方が良い。システム間連携でテキストファイル化して連携する事もしばしばあるし、現在システムで使われている、日本標準時で動く想定のものをあえて夏時間に変える必要はないだろう(将来的には、サーバのローカル時間に影響されないように修正する必要はあるのだが)。
利用者の「タイムゾーン」に合わせて、表示や、入力の際の時刻について対応する必要がある。
今まで利用者がタイムゾーンを意識して入力するような事はなかったのだが、入力者が意識して入力していなかった事がある。
出来ればクライアントや端末のロケールを認識して変換するようにした方が良い。
既存の、「タイムゾーンの変更で実装していなかった夏時間対応」を解除する必要がある。
今まで、ほとんどの先進国で用いられているタイムゾーンは+1時間で行われていた為、そういう実装が多い。むしろ、既存の「夏時間が来ても大丈夫」みたいな仕掛けが全て問題という事になる。
また、いつ何時間ズレの夏時間に入るかなどの情報は誰がいつどのように周知するか決まってない(下手にOSレベルで適用されると先の暫定的な「システムの記録時間はローカル時間で」が壊れる事になるし)。
電波時計も、プロトコルが「夏時間に入ったか」くらいしかなくて、時間は設定されていないので一時間想定のものが多いと思う。すべて問題になる。
「今までの記録をデータとして用いる場合の問題」が発生する。
レガシーデータのコンバートに、「夏時間なのかそうでないのか」なんてのを放り込む必要も出てくる。勘弁してほしい。
ローカル時間だけが保存されている状況なのに、「何年何月何日から夏時間」という事を外側の情報として保持しながら変換をしていく必要があるのだが。勘弁してほしい。
すべてのシステムの運用時間を、変更する必要があるかどうか検討しなければいけないのが、最悪。
重いバックアップが、朝8時までに終わってないとアラート上げるようにするとかの設定があったりするが、これは、要は人が働き始めるのが9時だという事から逆算的に設定されているものだ。
ぶっちゃけ、夏時間に変更される前にシステムとしてはバックアップしておきたいところなのだが、この「夏時間に変更される前にバックアップに使える時間が通常よりも二時間遅い」という問題は、かなりツラい。
下手すると前日は早めにシステム止めるとかの必要が出てくる。
人の動きが二時間も変わる事の影響はかなりデカイ。年二回のタイムゾーンの変更を考慮した運用設計が必要になる。