>>346
システムの動作に依存するパラメータが法令にある時刻で(労基法の深夜割増は22時からとか)、
そのパラメータがサマータイム例外規定とかで一部の工場は24時からとかになったらどうするのって話なわけで
UTCで管理してれば2時間のズレは表示上の問題でしかない、という話以上の問題がそこにはあるだろう

法令の時刻をDST実施中にUTC+9で読めばいいのかUTC+11で読めばいいのか現時点ではわからないのだから
例えば深夜割増の開始判定時刻は現状では365日JSTの場合しかないからUTCの13時と決まっているけれど、
今後の行政の動き次第では開始判定時刻がUTCの11時になったり、UTCの13時になったりとケースバイケースなわけで、
そんなの事前にシステム設計側で把握しておくことは不可能だっただろうって話だ。
そもそもJSTのローカルタイムのままシステムを動かすのか、JSTで表現されたローカルタイムをJDTとして再解釈して
システムを動かすのかもケースバイケースなわけで、スタンドアロンなシステムなら単なる決めの問題だが、
連携して動いているシステムでこの方針を統一できない場合もあってその場合はテストを相当にやりなおさなくちゃいけないだろう
ただそれを説明してお客さんが納得してくれるとも限らないからタイムゾーンを変えるなんてことを本当にやるのか？と皆思ってるわけで