位置データは正常系だけでなくエッジケースでもテストする
よく地図化された市の中心部の住所からは、システムが農村部のルート、係争中の国境、極地付近のクエリをどう扱うかについてほとんど何もわかりません。難しいケースを意図的にテストしてください。
30分単位と45分単位のタイムゾーンを解説
多くの開発者は、最初にタイムゾーンを処理するコードを書くとき、すべてのオフセットがUTCから整数時間ずれていると想定します。この想定は大多数のタイムゾーンで成り立ちますが、それに従わない場所から初めてリクエストが来た時点で破綻します。世界のいくつかの地域では30分単位のオフセットが使われており、少なくとも1つの地域では45分のオフセットが使われています。そして、これらはどれも、まれであるとか無効であるという意味でのエッジケースではありません。単に、それらの地域が太陽や近隣地域との関係で時計をそのように合わせることを選んだというだけのことです。
30分単位のオフセットは通常、その国の経度が1時間単位の2つの標準時帯の間にあり、どちらか一方に寄せるのではなく中間を取ると決めたことを反映しています。45分のオフセットはさらにまれで、同様の中間的な位置に加え、近隣の標準オフセットとあえて区別しておくという選択を反映していることが多いものです。どちらもデータの誤りではありません。どちらも正当な法定のタイムゾーンであり、IANAデータベースでは1時間単位のタイムゾーンと同じように管理されています。
これが実際にソフトウェアを壊すのは、想定をハードコードした日付や時刻の計算においてです。オフセットを最も近い1時間に丸めるコード、オフセットを時間単位の整数で保存するコード、1時間単位と30分単位の刻みだけでタイムゾーンのドロップダウンリストを作るコードは、これらのタイムゾーンを気づかないうちに誤って処理します。しかも、失敗は通常目立ちません。明らかなエラーが出るのではなく、時刻が15分や30分ずれるだけなので、テストでは見逃しやすく、影響を受ける地域の実際のユーザーがおかしいと報告して初めて表面化します。
最初からこれを考慮して作れば、対策は簡単です。時間単位を想定したり丸めたりせず、常にそのタイムゾーンについて返される実際のUTCオフセットを分単位の精度で扱ってください。可能な場合は、オフセットではなくタイムゾーン名を保存して比較します。名前には、何もハードコードしなくても、現在と過去の正確なオフセットが含まれているからです。
IANAのタイムゾーン名と一緒に正確なオフセットを返すタイムゾーン検索を使えば、ここでの推測は不要になります。オフセットは1つの国の中でも異なることがあり、どこでもきれいに1時間単位にそろうことはめったにないため、国や地域だけから場所のオフセットを推測するのではなく、座標やタイムゾーンを直接問い合わせてください。