サマータイム導入時のOSとアプリケーション

日本のサマータイム(+1 or +2時間)が現実のものとなったときのための調査メモ

OS側
ほとんどのOSがUTC(世界標準時)で動作しつつ、ローカルタイムもAPIによってアプリケーションへ提供している。したがって、現行OS(サポートが終了していない)は、アップデートにより日本のタイムゾーンを設定していれば、該当日時にローカルタイムを進めたり戻したりする。
サポートが終了したOSは、タイムゾーン設定による調整(サマータイムを導入した日本の場合)は行われないため、常に UTC + 9でローカルタイムが提供される。これらのサポート終了OSで夏時間を実現するには、タイムゾーンを UTC+10 または UTC+11 の地域に変更すればよい。

このときオーストラリアなど夏時間を利用している地域を選択すると混乱を生じる可能性があるので、その年に夏時間を導入しないであろう、ウラジオストクやサハリンを選択するのがベターかもしれない。
タイムゾーンを変更しても言語やデフォルトエンコードには影響は出ない(例: 日本人が海外で自身の端末を使う場合、タイムゾーンは変更しても言語は日本語のままといった状態)

アプリケーション側
多くのアプリケーションが、表示などについてはローカルタイムを利用しているハズ
ネットワーク関連のアプリケーションやファイルシステムではUTCを用いる事が多いが、表示を現地時間に合わせるため UTCからの時差をOSから取得したりローカルタイムへAPIを利用しているので、結局ローカルタイムに依存することとなる

ローカルタイムを利用したアプリケーションで問題になるのが、サマータイムへ切り替わる時間帯と、戻る時間帯に運用しているアプリケーション。
切り替わり時には、1 or 2時間一気に時刻が進むことになり、製造ラインなどで大きな問題が出る可能性がある(1時間かけて投入する材料を一気に投入するような事故)。
戻る時間には、同じ時刻が 1 or 2時間発生するので、製造ラインなどで先程の逆の事や、受注順序の判別が不能などの可能性。
問題が起こる可能性が考えられる場合、予めOS側で夏時間への切替をオフにしておく

OS側の設定が変更できない環境の場合、UTC + 9 を常に計算する等の修正が必要になるが、それなら UTC とローカルタイムを利用するように根本的に変更すべきかもしれない

ローカルタイム + タイムゾーンからUTCを取得することは可能だが(Win: GetUtcOffset)夏時間終了前は、同じ時間が2度訪れるため、何らかの形でUTCを記録しておくしかない