サマータイムがなんでダメなのか、システム屋視点で。

「朝7時に起きてるオレが5時に起きるわけだろ」とか「18時に仕事終わるはずが16時に終わるわけだろ」的な標準時とサマータイムの差が嫌だみたいな感想はどうでもいい。まじでどうでもいい。2日目以降は通常の24時間サイクルなんだから、問題ないことに気がつけよと思う。太陽の傾きが健康に及ぼす被害があるかもしれないけど、そんなもん気にしなくていいって、前例はたくさんあると思うよ(未検証)。
でもね、システム屋視点で何がいやか書いておく。いや、ほら、検証に何年もかかるみたいなざっくりした批判がIT屋の総意みたいに取られても面白くないんでね。
要するに「できない」んじゃなくて、最初から(設計段階から)言っといてくれれば、ちゃんと動くように作れるのに、短い期間で後から対応するのが不可能なだけ。

2020年の5月のある日、日本にサマータイムが導入されたとしましょう。
5月下旬のある日、未明の「一般生活に影響がないと思われる早朝」のタイミングで導入されるとする。
深夜1時59分59秒の次に4時00分00秒が来る、と仮定しましょうか。
そうするとこの日は2時台と3時台の時刻が存在しないわけですよ。
ということは、まず、毎晩2時台とか3時台に取得することにしてるバックアップを実施するトリガーがないわけです。
サマータイムが導入されて何か起こるかわからない日のデータのバックアップ取れないことになるわけ。
その日だけ早めにバックアップすればいい？いやだから、1時台までにいろんな処理が終わったあとで2時台にバックアップしてるわけで、バックアップだけ早い時間にやればいいわけではないのはわかりますよね？データの更新終わってなくて前日のバックアップと同じデータのバックアップが取れてしまっても意味ないっしょ？全部の処理をちょっとずつ前倒しするの？その動作確認する？まじで？そこの再設計と検証が大変なんだよって話だよ。単一のシステムではなく、いろんなシステムが処理をして、翌朝の決済とか配送の処理してるのに、2時間たりなかったら、処理終わらないかもじゃん！誰が責任取ってくれんのよ、これ。

いや、神業的処理でサマータイム導入時を乗り切った俺たちの次の関門はサマータイムをやめる日。
深夜3時59分59秒の次に2時00分00秒が来るのかよ。その日2回めの2時台と3時台かよ。ふつーにバッチまわったら、重複処理になるだろう。お客様へ同じ商品2個届くよ。在庫足りなくなって自動発注かかるよ。それ、返品来るよね。おいー、まじかーってなるでしょ。1回めの3時台にパスワード変更したら、2回目の2時台はそのパスワードでログインできるべき？1回目の3時台のお客さんの方が2回めの2時台のお客さんの方が先だってこと、どうやってシステムに理解させればいいんだろう？これを起こさないように手配して実装してテストすんのか。あ、でも2回めの2時代の注文は全部ナシにしてはいかんわけだしうおー、気が狂いそうだ。
＃あ、その2時間はサービス止めちゃえばいいのか(悪魔のささやき)。

∴サマータイム導入に反対です