はじめに
すでに報道されていて話題になっていますが、仮にオリンピックに向けたサマータイム導入が決定された場合、主にプログラム方面で考慮する箇所を列挙してみました。
- ログファイルの記録時刻をUTC基準にしないと、サマータイム終了時に同一時刻が二回出現する為、ログファイルやログ情報の書き潰しが発生するかもしれません。
- 現状、時刻情報しか保持していないシステムのデータベースや電文の項目は、JSTなのかJDTなのかUTCなのかわからなくなってしまうため、タイムゾーン情報を追加する必要があるでしょう。
- プログラム内にて「次の日」を期待して、現在秒に「+=24*60*60*1000」や「+=86400」などと処理しているような個所は、仕様として「24時間後」のままでよいのか「翌日の同時刻」でないといけないのかをはっきりさせる必要があります。
- 現状、日本(JST)と韓国(KST)は同一のUTC+9の為「日本と韓国に時差はない」という暗黙の前提に依存してしまっている処理の有無の洗い出しが必要になるでしょう。
- プログラム言語、ライブラリ、ミドルウェア等の時刻関連機能のタイムゾーンのサポート状況を詳しくチェックする必要があります。サマータイムに対応していても1時間シフト固定の実装になっているものはそれほど珍しくありません。
勿論このほかにもサマータイム開始直後に時刻が飛ばされる事による、タスク/ジョブの未実行問題やそれに伴う前後依存関係の前提条件の破綻といった運用上の問題もてんこ盛りです。
それでは今日はこのへんで。