サマータイムはタイムゾーンの一種と考えることもできるので(該当時期だけタイムゾーンがずれると解釈できる)、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。
アメリカの場合はタイムゾーンが西部、中部、東部と3つあるので国内向けのシステムでもほとんどがタイムゾーンを意識して作られているし、そもそもタイムゾーンが導入されてから長い。
ところが、日本はどうだろうか?
日本は結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。
複数タイムゾーンに対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間に対応するのが一般的だ。
サマータイムになろうが、別タイムゾーンに飛行機で移動中であろうがUTCは常に進み続ける。(正確にはうるう秒があるので1秒間足踏みしたりするのだが)
ローカルタイムはサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータを並べ替えたりするのには使えないのだ。
ちなみにアメリカ軍の戦闘機F-22が日付変更線を超えて沖縄に初めて来たときソフトウェアがバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。
さて、日本中にある既存のシステムはどうだろうか?君の作ったシステム、関わったシステムはどうだろう?
MySQLのシステムタイムゾーンをJSTにしていたりしないか?
「JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん?だって日本人しか使わないんだぜ?言語のバリアがあるからね(はぁと」
なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。
他のシステムと相互通信するソフトウェアはどうだろうか?相手のタイムゾーンがJSTであると仮定していないか?アメリカ西海岸から接続があった時も大丈夫か?
てか、そもそもロジックと表示部分がちゃんと分離されているか?モデルとビューの分離。教科書でならっただろ?
おいおい、ビューで計算したものをモデル側で未チェックで保存したりしてないよな?
テストは書いてあるか?タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか?
そもそもテストは書いたことあるのか?てかソースはそもそもあるのか?
あー・・頭痛くなってきた。やめよう。
「大臣、無理です!」
幸いJSTはサマータイムの変動がないので、JST - 9 すれば全部 UTC に変換できる。 というわけで、JSTで保存しているプログラムも内部はそのままでUI部分だけ変えれば無理くり対応できる可...
なんか末期がん患者の延命治療だな。 どうせやるなら根本的にやっておいたほうがいいと思うが・・
もう鎖国したらいいんじゃね?日本でしか通用しないジパングタイムを提唱します!
最近の(ネットで有名な)プログラマーは、プログラム作るばっかりで、(くそコード)保守の経験が少ないからのう。 COBOLから移行したシステムは、たとえCで書いてあっても、ロジッ...