「サマータイム導入はコンピュータシステム的に難あり」は本当か (1/2)
サマータイムは簡単、という記事があまりにあれな件 - novtanの日常
タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ
サマータイムの話。
結局のところ「データ」としてローカル日時を持ってしまっているシステムが多数あり、それらがどれくらい影響するかわからない、ということが皆が反対する理由。
対策としては結局3つ目のブログに書いてあることがすべてで、システムの内部では一貫してオフセット付きの日時またはUTCでデータを持つべきで、システム境界を超える場合も可能な限り(ユーザーに不要な手間が増えるといった例外を除き)オフセット付きで時刻を扱いましょう、というだけの話。
それで、「ローカル日時を持っているデータ」って十中八九文字列ですよね？2018/08/19 23:00とか、201808192300みたいな文字列ですよね。それをDBに入れたりファイルに書き出したりしてるってことですよね？そういうの、もうやめませんか？そもそもなんのためにそんな事するの？っていうお話です。
なぜわざわざローカル日時でデータをもつのか
java:OffsetDateTime (Java Platform SE 8)
.NET:DateTimeOffset 構造体 (System)
文字列書式:ISO 8601 - Wikipedia
上記あげた*1ように、各プログラム言語でも絶対日時を持って便利に使える型が用意されているし、文字列書式も国際規格があります（もちろん文字列⇔オブジェクトの変換も一意的に行える）。にもかかわらずどうしてオレオレ文字列書式を考案してシステムに組み込んでしまうのでしょうか。
違いまーす。コンピューターが用いているのは、「データ」と「システム時刻」です。データには時刻の関連項目がありますね。みなさんに一番身近なのはファイルの更新時刻とかですね。ブログの更新時間なんてのもデータで持ってますよね。表示されるでしょ。まさかこれをずっと「内部時間で刻んている」わけないよね。X時間前、という更新時刻は当然XX:XX時というデータと今の時刻の比較をしているので、システム時間をバーンと変えたらX時間前との相対関係が変わって表示変わっちゃいますよね。
説明のためかもしれませんが、さも当然のようにブログの更新時刻をXX:XXデータでもってると言い切ってるあたり、サマータイム云々関係なく、またレガシーシステム云々も関係なく、日時を文字列で持つのが当然という意識が蔓延してることを示してますよね・・・（というかこの説明に関してはいろいろ・・・）
日本国内限定のシステムだから201808192300って書式のほうが誰が見てもわかりやすいから？
とはいえ連携するシステムやクラウドサービスなど、まともなシステムは絶対日時で日時表現してくるのであっちこっちでオレオレ書式に変換しなければいけませんよね？それに、文字列書式のままでは時刻演算(n日足すとかn時間足すとか)が困難なので、その度にParse/Serializeしなきゃなりませんよね。
正直これまわりでプログラマーもどきが「なんだかわからないけど9時間ずれるんです」とか言われたの1度や2度ではないのです。いったいなんのために確立した形式があるのにオレオレ方式を考案してバグや混乱を生み出すのでしょうか。
諸悪の根源は「ともかくわかりやすいから文字列にする」という風潮や単なる昔からの流れであると思われ、そういうわけのわからない悪習はもうやめてほしいと思うのですがいかがでしょうか。
おまけ
中小企業向けの会計ソフトを手がけるＩＴベンチャー「ｆｒｅｅｅ（フリー）」（東京）の社内ＳＮＳでは、政府のサマータイム検討方針が報じられた６日、エンジニアや営業担当者らから疑問を投げかける投稿が相次いだ。
(中略)
エンジニアの浅越光一さんは「対応に１カ月かかるのか、半年かかるのか、やってみないとわからない。その対応にかける時間があれば、新サービスの開発がどれほどできるかと思うと、もったいない……」とため息をつく。
レガシーシステムを多数抱える会社ならともかく、さすがに2012年創業の会社で、海外進出をめざしてるクラウドサービスの会社がこの感じはかなりイメージダウンだとおもうのですがいかがでしょうか（好意的にみれば自社サービスは大丈夫で連携システムのつなぎを心配していると取れなくもないですが）
*1:ここにあげた仕様は比較的新しいものが多いが、しかしコンピューターの日時表現の基本は絶対日時であるUNIX timeであり、伝統的なプログラミング言語の日時型はそのラッパーなので、古い言語であっても絶対的な日時を保持するのはそれほど難しくない
