■妄想でサマータイムに対応してみようとしてみる

サマータイムはタイムゾーンの一種と考えることもできるので（該当時期だけタイムゾーンがずれると解釈できる）、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。

アメリカの場合はタイムゾーンが西部、中部、東部と3つあるので国内向けのシステムでもほとんどがタイムゾーンを意識して作られているし、そもそもタイムゾーンが導入されてから長い。

ところが、日本はどうだろうか？

日本は結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。

複数タイムゾーンに対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間に対応するのが一般的だ。

サマータイムになろうが、別タイムゾーンに飛行機で移動中であろうがUTCは常に進み続ける。（正確にはうるう秒があるので1秒間足踏みしたりするのだが）

ローカルタイムはサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータを並べ替えたりするのには使えないのだ。

ちなみにアメリカ軍の戦闘機F-22が日付変更線を超えて沖縄に初めて来たときソフトウェアがバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。

さて、日本中にある既存のシステムはどうだろうか？君の作ったシステム、関わったシステムはどうだろう？

MySQLのシステムタイムゾーンをJSTにしていたりしないか？

「JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん？だって日本人しか使わないんだぜ？言語のバリアがあるからね（はぁと」

なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。

他のシステムと相互通信するソフトウェアはどうだろうか？相手のタイムゾーンがJSTであると仮定していないか？アメリカ西海岸から接続があった時も大丈夫か？

てか、そもそもロジックと表示部分がちゃんと分離されているか？モデルとビューの分離。教科書でならっただろ？

おいおい、ビューで計算したものをモデル側で未チェックで保存したりしてないよな？

テストは書いてあるか？タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか？

そもそもテストは書いたことあるのか？てかソースはそもそもあるのか？

あー・・頭痛くなってきた。やめよう。

「大臣、無理です！」

Permalink | 記事への反応(2) | 02:12

ツイートシェア