ずいぶん涼しい季節になりました。サマータイム案は何事もなくボツりましたね。夏を越えられなかったか。IT屋としては残念。特需を逃した？ いやそういうことじゃなくて、数学的な議論もなく不可能と断言されると、エンジニアとしては違和感しか感じないので。そこで使うべきじゃない言葉。実際のところ、お金をいくらかけるかってだけの話です。その上で「費用対効果悪すぎるんだろうな」という感覚はありました。省エネや余暇創出の効果なんてほとんどないでしょ。大騒ぎすればできるだろうけど、やる意味なさそう、というね。
今回意外だったのが電波時計のプロトコルの話。DSTの情報までやり取りしてたんかいっ！ っていうね。今でも信じられないけど、クソ仕様やらかしたなー、と。単なる時刻同期だぞ？？ 判断ミスとしか思えないな。受け取り側でタイムゾーンのデータベースを持つべきでしょう、ファームウェア更新は空から降ってくるようにしよう、と計算機屋なら考える(?)。それはもっともだが時計屋の考えは違った。確かに、電波時計って国や地域によって違うもんな。それで、時計によっては複数の対応地域があったりする。変なの。メモリもCPUもストレージもないハード。
時刻情報の内部表現に関しては、struct timeval/timespec(unix timeとusやns単位の値が入ったstruct)が最も優秀と思っている。Pythonみたいに1つの浮動小数点数でもいい。それをタイムゾーン情報に合わせてどう解釈して外部表現に変換するかはOSや標準ライブラリの仕事よね。そこを独自で決め打つような時代は化石の中にしかなく、2000年問題のときに駆逐されたでしょう。ただDBMSのDATETIME型とかね、うんこ仕様みたいなやつありますね。システム屋は多かれ少なかれDBMSを相手にしますんで、いつもうんこうんこ…と思いながらDATETIME使ってます。
案に関していろいろ意見を言う人がいましたけど、OSのタイムゾーンの管理方法の解説から実験まで、sakuraの人が公開してくれた情報が最も有益だったように思いますね。URL忘れたけど。まあこの小さな騒ぎで少しは勉強になったよ。
残念だったのはスポーツ界の反応かな。だつてJリーグなんて最もデメリットの大きい競技団体じゃないですか。夏開催どうすんのよ。7時キックオフですら暑さで地獄の様相なのに。もし決まってたらさぁ…試合、朝やんの？ それとも9時キックオフで試合中に終電気にさせる？ 室内スタジアムで空調効かせる？？ IT屋の比ではないほど実現困難性が高すぎた。