2018-08-11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大臣、無理です!」

  • anond:20180811021253

    幸いJSTはサマータイムの変動がないので、JST - 9 すれば全部 UTC に変換できる。 というわけで、JSTで保存しているプログラムも内部はそのままでUI部分だけ変えれば無理くり対応できる可...

    • anond:20180811023245

      なんか末期がん患者の延命治療だな。 どうせやるなら根本的にやっておいたほうがいいと思うが・・

      • anond:20180811025153

        もう鎖国したらいいんじゃね?日本でしか通用しないジパングタイムを提唱します!

  • anond:20180811021253

    最近の(ネットで有名な)プログラマーは、プログラム作るばっかりで、(くそコード)保守の経験が少ないからのう。 COBOLから移行したシステムは、たとえCで書いてあっても、ロジッ...

記事への反応(ブックマークコメント)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん