サマータイム盛り上がってますね！
ほんとにヤバイからやめろとか、どういう形で対処したらいいかみたいな話もいろいろありますが具体的に死ぬパターン集みたいなのは見当たらないので思いつくやつを書いてみました。
目次
サマータイムのおさらい
サマータイムとは。
ざっくり言えば夏の間だけ時計を進める処置です。時計であって時間が進むわけではない。
例えばアメリカのラスベガスやロサンゼルスなどでは、3月の第2日曜日午前2時から11月の第1日曜日午前2時まで、1時間進んだ時計を使います。そして期間が終わったら1時間戻します。
これは太平洋夏時間(PDT)として定義されてもいます。サマータイムではないときは太平洋標準時(PST)です。
日本が0時のときPDTだと前日8時、PSTだと前日7時になるようです。
※提案されている日本サマータイムは1時間ではなく2時間のようです。ただサマータイムとしては1時間ずれのほうが多数であることや、例示しているPDTが1時間であることから、本記事では1時間ずれを例としていきます。ややこいですね。
どうして混乱しないシステムがあるのか
もともと夏時間に限らず、世界各地には時差があります。基準となる時間が協定世界時(UTC)として定義され、各地の時刻はUTCから何時間ずれているかを表す形で計算されます。
例えば日本だと、9時間ずれているためUTC+9となります。これにJSTと名前が付いています。
各国のデータを扱う場合には混乱しないように、基準となるUTCで管理し、それぞれの状況に合わせてJSTだったりPSTだったりで表示すれば問題ありません。そうなっているのであれば、夏時間も乗っかるだけで大丈夫ってわけです。
(とはいえ集計などで人の手が入るときは厄介に思いますがそれはそれ。システム上の整合性が崩れることはないです)
ちなみに表示については、Windowsとかだと夏時間になったら自動的にそちらに切り替えてくれるみたいです。へー。
UNIX時間を使うシステムも混乱しない
またUNIXなどサーバー系では、1970年1月1日からの秒数をカウントしたUNIX時間を基準時刻として使用することも割とあります。こちらを基準にデータを扱っている場合も問題ありません。
サマータイム死亡パターン
つまりこういったことを考慮してなくて、日本のパソコンに出てる時刻をそのまま使ってるだけだと死にます。
日時の切り替えはバチっと電源を落として、その後の立ち上げで日時の変更をすればよいだけを想定してやりますね。
日付を詰めているパターン
例えば2018年8月15日を「20180815」としているパターン。YYYYMiDDとかそういうのですね。
1時20分まで含めて、「20180815012000」とか「20180815_012000」とかで作っている奴。割とメジャーじゃないでしょうか。
サマータイム開始で1時間進めるときは歯抜けが出来る程度で済みますが、1時間戻したときに重複するデータが大量に出て死にます。
独自にデータファイルに入れているパターン
ここまで詰めていなくても、「2018/08/15 01:20:00」と記録したCSVを作っていたりしないでしょうか。
同様に1時間戻したときに重複して死にます。
日付をユニークキーにしているパターン
データを作るときに重複しないために、日付を(特に詰めて作った日付文字列を)キーにしている場合はありませんでしょうか。
1時間戻したときに重複して死にます。
特定の時間に動作するプログラムを作っているパターン
cronのバッチ処理など、毎朝○時に走っている重い処理がある場合のことです。
1時間進めたときに手動で実行し忘れると死にます。
1時間戻したときに実行を止めておかないと二重に処理されて死にます。
後者は何度実行しても大丈夫なように設計されていれば問題はないかもしれません。1日1回実行することだけを想定しているプログラムだと死にます。
さらに、バッチ処理は数時間～掛かる処理がまとめられていることもあると思います。サマータイム切り替えタイミングに被らないといいですね。境界となる時間を超えた後は、時計が一時間進んだ間違った状態で処理が進みます。集計処理とか死にそうです。途中で止めるか間違ったまま走り続けるか選択の時がやってきます。
ネットワーク時刻調整で巻き戻るパターン
サーバー系のシステムは昔から、ネットワークで時刻を調整するようになっていることが標準です。
スマホやパソコンなんかでも実は自動的に調整されています。電池が切れた後に立ち上げ直しても、昔のゲーム機みたいに自分で設定しなくて済むのはこれのおかげでもある。
例えばAndroidだと次のような設定項目があったりします。
手動で変更するなら、この仕組みをオフにしておかないと／期間中はオンにしないようにしないと速攻元に戻って死にます。
「おうちの時計の針をみんながそれぞれ進めればいい」程度に考えてる人が無事死亡するポイントですね。
(ntpdなんかはあまりにズレすぎると異常検知して自動更新をしなくなったりしたと思うので、どうなるかはそれぞれのシステム次第になりますが)
じわじわ時刻がずれてくパターン
ネットワークの時刻調整をオフにすると、当然それぞれの機器で時刻を刻むことになりますが徐々にズレていって数分くらいは平気でズレて死にます。
デジタル時計などが微妙に遅れてて直したりとかした経験ないでしょうか。ネットワーク経由のこまめな時刻調整が無いと、コンピューターとかでも意外とずれてしまうものだと経験的には思います。
通信元／通信先がサマータイム対応してないパターン
上記のような時刻合わせの例もあったり普通に間に合わなかったりして、通信先がまだサマータイムになっていない場合、同時に通信しても向こうとこっちで1時間ずれて死にます。
身近なところだとゲームとかでしょうかね。スタミナとか時間で回復するやつ。基本的にはサーバー側の時間で管理するようになってて問題はないと思うのですが、表示がおかしくなる程度はあるかもしれない。
また海外は変わらずJSTで送ってくるかもしれません。AppleやGoogleやMSがOSレベルで対応してくれるといいですねって話とか。
(タイムゾーンとして正式に組み込まれたら自動的に切り替わるだけかもしれないですね。そのあたりはどういう手続きでやるのか分からないけど)
2020年夏が死守できないパターン
今回最大の死亡ポイント。2020年夏が必達の締め切り。
そのきっかけがスタートしたのが2018年夏。(まだ決まってない)
正直、サマータイム自体は(面倒だが)システム的には時間があれば対応できる代物です。逆に言えば2020年夏までに出来るかと言われると死ぬ。
また、ちゃんとした方法は他地域のサマータイムみたいにタイムゾーンに組み込んで自動的に切り替わるようにすることかもしれませんが、もしそれが成った場合は半強制的に切り替わることになり対応できてないシステムが死ぬ。
「技術的にできるかできないか」みたいな話しかしていない方々が「君、ちょっと、黙れ」みたいな扱い受けるのはこういうとこです。
さいごに
とりあえず思いつくだけ書いてみたらサマータイム割と死ぬ。
当てはまるパターン、当てはまらないパターンあると思います。実際こうなるかはわかりません。
さらに死ぬパターンが世の中にはあるかもしれません。みなさんも自社のシステムで死ぬパターンとか考えてみるととても面白いのではないでしょうか。
参考：
