サマータイム関連
タイムゾーンを考慮した日時の扱いのベストプラクティス
Linuxでのサマータイム - JDTの来襲
こういう具体的な話もありがたい。
日本人の書いた夏時間で不具合を起こすプログラムというのは、いってみれば米国人の書いた日本語を入力できないプログラムのようなものである。
僕が手がけた情報システムにおいて、発注の段階で夏時間対応を入れることができただろうか。それを入れるということは、発注仕様書に要件として書き込み、仕様検討やらコードレビューにおいてそういった視点を要求し、テストでタイムゾーンを切り替えたり、時間の切り替わるところ（特に夏時間から標準時に戻すところ）でジョブネットがおかしな動きをしないか、ログやデータベースの中身に矛盾がないか、そういうことをちゃんと調べるということだ。今月以降に発注する分であれば、まあ秋の臨時国会で何が起こるか分からないから念のために仕様書に組み込んでおこうかという判断もあるのかも知れないが、自分が3年前とかに主張したならば何が趣味で過剰品質を追い求めているのかと問われて答えられないだろう。
『Excelにタイムゾーンという概念がなく、サマータイムに対応しないということは』『これから未来永劫、時限サマータイムの2年間についての複雑な特別処理を仕込まないと、正しい集計ができなくなります』
サマータイム導入が難しい理由、迫られる「2度訪れる同時刻」への対応
「サマータイム導入はコンピュータシステム的に難あり」は本当か - BLOGOS
同コメント(forum)
宮脇睦さん「サマータイム導入なんてバチっと電源を落として日時を変更すればいいだけ」記事に批判殺到 - togetter
あー、炎上している。
「サマータイム導入はコンピュータシステム的に難あり」の記事のヤバさを業界外向けの人に解説します
コンピュータシステムのサマータイム対応を巡る二つの楽観論 8/7
日本のプログラムでは、普通、10:00 に投稿したら、そのまま「10:00」という情報を保存する。そして、専用ブラウザに対して、「10:00」という情報を送信して、専用ブラウザは、それに何の変更もしないで、「10:00」と表示する。
どちらが自然だと思いますか？
10:00 に投稿された情報を「10:00」で保存するのと、10から9を引いて「1:00」で保存して、表示する時に9を足して、「10:00」で表示するという二度手間をかけるのと、どちらが自然だと思いますか？
この「9を引いて」とか「9を足して」という処理が、サマータイム期間中は「11を引いて」と「11を足して」になる。こういう所は、国際化の機能を使うと自動的にやってくれるのだが、日本人しか使わないものは、そもそも足したり引いたりする処理を入れる必要がなくて、自然に10:00で保存して自然に10:00で表示する。
それは、国際的に見て標準的とは言えないし、今後はそれではダメだろうと私も思うが、日本人が日本国内でプログラムを作ると、5chのようなやり方になるのが自然だ。
それに、仕事で作るプログラムでは、エンジニアが必要と思っていても客が必要と思わなければ、そういう機能を入れることは許されない。
はい、自然な感じでやっております。
過去に1件だけ、1件だけ、海外を、タイムゾーンを意識したことがあったが、DBには日本時間で格納していて、相手のタイムゾーンに合わせて変換して表示していた。
当時UTCでという発想はなかった。
MySQLは log_timestamps=SYSTEM にする。もちろん。
現在進行形で関わっているサービスが、海外からも利用されるが、日本時間ですべてが動いている。
海外向けはおまけみたいなもんで、ローカライズはしない、むしろ日本人向けをそのまま提供するのが要件だから、別にいいよね。
コンピュータシステムのサマータイム対応を巡る2つの楽観論 - スラド
「2020年に向けてのサマータイム導入は絶対ムリ」がよくわかる、立命館大学・上原哲太郎教授らのツイート - togetter
2020年にあわせたサマータイム実施は不可能である 8/10
サマータイムは不可能である - アゴラ 8/10
「サマータイム実施は不可能」スライドが話題 「経済被害が兆単位」「サイバーテロをお膳立て」立命大・上原教授が指摘 8/10
NET Framework における時差情報（サマータイム）の取り扱い
コンピュータによる「夏時間」の扱い方についての解説 2011/03/31
