位置データは正常系だけでなくエッジケースでもテストする
よく地図化された市の中心部の住所からは、システムが農村部のルート、係争中の国境、極地付近のクエリをどう扱うかについてほとんど何もわかりません。難しいケースを意図的にテストしてください。
タイムゾーンのルールを変更した国々
ある国のタイムゾーンを一度知れば、それはずっと変わらないと考えがちです。実際には、政府がタイムゾーンの方針を変えるのは、多くの人が思っているよりも頻繁です。ある国は、何十年も夏時間を使ってきた後にその採用をやめると決めるかもしれません。別の国は、主要な貿易相手国により近づけるために標準のオフセットを1時間ずらすかもしれません。大きな国は、地域行政の変化に伴って、国内の2つのタイムゾーンの境界を引き直すかもしれません。これらはどれも仮定の話ではありません。個々の国で見れば次の変更まで何年も何十年もかかることがあっても、このような変更は世界のどこかでかなり定期的に起きています。
IANAタイムゾーンデータベースは、まさにこの問題を解決するために存在します。国ごとに現在のオフセットを1つ保存するのではなく、名前の付いた各タイムゾーンをルールの時系列の履歴として管理し、政府が変更を発表するたびにエントリーが追加されます。保守され定期的に更新されるこのデータベースのコピーを利用するソフトウェアは、自身のコードを一切変更せずに変更を取り込めます。一方、国ごとのオフセットをハードコードしているソフトウェア、たとえば初期開発時に一度だけ書かれた対応表を使っているソフトウェアは、対象の国のいずれかが次にルールを変更したとき、気づかないうちに誤った状態へずれていき、その不具合は自ら知らせてはくれません。誰かが気づくまで、その国についてだけ誤った現地時刻を返し始めるだけです。
これは、名前の付いたタイムゾーンと切り離してUTCオフセットだけを保存することが、数か月を超えて使うデータにとって危険である理由でもあります。今日取得したオフセットは、変わる可能性のあるルールのスナップショットにすぎません。Pacific/AucklandやAsia/Kolkataのようなタイムゾーン名は保守されたルールセットへの参照を持っているため、基になるデータベースが最新に保たれている限り、その名前に基づく計算はルールの変更後も正しいままで、自分のデータに手を加える必要はありません。
タイムゾーンのデータを基に開発する人にとっての実践的な指針は単純です。自分のデータベースには、生のオフセットではなくタイムゾーン名を保存してください。依存しているタイムゾーンのライブラリやデータソースは、適切な間隔で更新し続けてください。古いコピーは、対象の国がルールを変更した瞬間に、ハードコードされた表とまったく同じように振る舞うからです。そして、タイムゾーンの検索は、無期限にキャッシュする値としてではなく、実際に変化する日付に結びついた計算のたびに新たに呼び出すものとして扱ってください。
当社のタイムゾーン検索は、任意の座標について現在のIANAタイムゾーン名とオフセットを、固定の表ではなく保守されたルールセットに基づいて計算して返します。各国が時とともに独自のルールを調整していくなかで正しさを保つ方法は、これしかありません。