位置データは正常系だけでなくエッジケースでもテストする
よく地図化された市の中心部の住所からは、システムが農村部のルート、係争中の国境、極地付近のクエリをどう扱うかについてほとんど何もわかりません。難しいケースを意図的にテストしてください。
タイムゾーンデータ：ルールは実際にどのように維持されているのか
タイムゾーンは、地理的な決定である以前に政治的な決定です。2つのタイムゾーンの境界線、夏時間を実施するかどうかの決定、時計を進めたり戻したりする正確な日付は、すべて国や地方の政府が定めており、そのどれもが変わる可能性があります。だからこそ、タイムゾーンデータは過去のある時点で固定されたオフセットの静的な表であってはならないのです。履歴、現在のルール、そして判明している将来の変更をメンテナンスし続ける記録でなければなりません。
ほとんどのソフトウェアがIANAタイムゾーンデータベースを参照しているのは、まさにこの理由からです。その管理者たちは、政府が発表する法定時刻の変更を追跡しています。夏時間の方針の変更、地域が採用するUTCオフセットの変更、国内のタイムゾーン間の境界の調整などです。Europe/AmsterdamやAmerica/Chicagoのような名前付きの各タイムゾーンには、現在のルールだけでなく過去のルールの完全な履歴が含まれています。ソフトウェアは今日だけでなく、過去の日付についても正しいオフセットを計算する必要があることが多いからです。
その履歴は、思う以上に重要です。数年前のタイムスタンプには、その日付に実際に有効だったオフセットが必要であり、その間にルールが変わっていれば、今日有効なオフセットとは異なる場合があります。現在のルールしか知らないタイムゾーン検索は、過去や将来の日付に対して気づかないうちに誤った結果を返します。だからこそ、日付が重要な場合は、タイムゾーン名だけでなく、特定の時点におけるタイムゾーンをタイムゾーンAPIに問い合わせる価値があるのです。
タイムゾーン検索が数値のオフセットだけでなく実際のタイムゾーン名を返すべきなのも、このためです。Europe/Amsterdamには、その背後にある履歴と夏時間のロジックがすべて含まれています。+01:00は1年のうち一部の期間にしか正しくなく、いつ変わるのかについては何も教えてくれません。地点のオフセットだけを保存するソフトウェアは、次に夏時間の切り替えが起きたときに正しさを失っていきます。一方、タイムゾーン名を保存するソフトウェアは、基になるデータベースが最新に保たれている限り、いつまでも正しいままです。
My Geocodeのタイムゾーン検索は、IANAのタイムゾーン名とUTCオフセットを合わせて返します。また、特定の時点を指定できるため、今日のルールが常に適用されていたと仮定するのではなく、その正確な日付に対して夏時間を含む正しいオフセットが適用されます。