位置データは正常系だけでなくエッジケースでもテストする
よく地図化された市の中心部の住所からは、システムが農村部のルート、係争中の国境、極地付近のクエリをどう扱うかについてほとんど何もわかりません。難しいケースを意図的にテストしてください。
過去のタイムゾーン変更と、それが今も重要な理由
タイムゾーンのオフセットを計算するソフトウェアは、あるタイムゾーンの現在のルールがずっと適用されてきたと暗黙のうちに想定していることがよくあります。この想定は、直近のルール変更より前のタイムスタンプを正しく解釈する必要が生じるまでは問題なく機能しますが、その時点で、まったくもっともらしく見える誤った答えを黙って出してしまいます。これは、かなりの期間にわたる過去のタイムスタンプを保存または処理するシステムで、微妙なデータ破損を引き起こす、実際によくある原因です。
これが重要なのは、タイムゾーンのルール、つまり夏時間の開始日と終了日、標準のオフセット、さらにはある場所がどのタイムゾーンに属するかさえも、永遠に固定されているわけではないからです。別の記事で取り上げたとおり、これらは政府が変更すれば変わります。何年も前に記録されたタイムスタンプについて、別のタイムゾーンやUTCでの対応する正しい時点を計算するには、今日有効なルールではなく、その特定の日付に実際に有効だったルールが必要です。
まさにこの理由から、IANAタイムゾーンデータベースは、名前の付いた各タイムゾーンについて、現在のルールだけでなくルール変更の完全な履歴を保存しています。これを基に正しく作られたソフトウェアは「この特定の過去の日付に、このタイムゾーンのUTCオフセットはいくつだったか」に答えられます。これは「このタイムゾーンの現在のUTCオフセットはいくつか」とは本質的に異なる、より複雑な問いであり、この2つを混同することこそが、過去のタイムスタンプのデータが知らないうちにずれていく原因です。
これは具体的かつ実際的な形で表れます。分析のために過去のログのタイムスタンプを現地時刻からUTCに変換するシステムには、現在のルールではなく、そのログの元の日付とタイムゾーンについての過去のルールが必要です。そうでなければ、変換によって誤差が生じ、関係する切り替わりによっては前後どちらの方向にも最大1時間ずれることがあります。過去のルール変更をまたぐ日付の範囲で、誰かの年齢や契約の期間を計算するシステムにも同じ注意が必要ですが、その影響は通常もっと小さくなります。古いタイムスタンプをユーザーの現在の現地時刻で表示し直すだけでも、現在のルールではなく、元のタイムゾーンと日付についての正しい過去のルールを通して変換する必要があります。
実践的な指針としては、タイムゾーンの変換は常に、現在のルールしか知らないシステムではなく、対象となる特定のタイムゾーンと日付について過去のルール変更を把握しているシステムを使って計算すること、そしてルール変更を含む可能性のある期間にわたって過去のデータを一括変換する処理には特に注意することです。私たちのタイムゾーン検索は特定の時点を指定して問い合わせることができ、その日付に実際に有効だったルールを適用します。これはまさに、実際に処理している日付に関係なくすべての計算に今日のルールを当てはめるのではなく、過去のデータを正しく扱うために必要な挙動です。