チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
タイムゾーンをまたぐリモートチームの調整
「UTCマイナス5時間」はタイムゾーンではなくオフセットです。そしてオフセットは、夏時間を採用しているほとんどの国で年に2回変わります。まさにそのせいで、12人のリモートチームが設定する会議は、何か月も正しい時刻に収まっていたのに、スケジュールを担当する側の誰も確認しようと思わなかった時計の切り替えの前後で、突然ずれるようになったのです。
チームは、各メンバーの都市を本社からの固定オフセットに対応づけた簡単なスプレッドシートを管理しており、誰かが夏時間が近いことを思い出したときに手作業で更新していました。すべての国が同じ日程で夏時間を採用しているわけではなく、まったく採用していない国もあるため、どの国が時計を切り替え、どの国が切り替えていないかによって、このスプレッドシートは入れ替わりながら1年のおよそ半分の期間、間違っていました。
解決策は、誰かが一度入力したスナップショットではなく、実際のタイムゾーンのルールを反映した検索にスプレッドシートを置き換えることでした。チームは各メンバーの都市について座標を割り出し、それを/v1/timezoneに送りました。このエンドポイントは、その地点のIANAタイムゾーン名を、単なるオフセットではなく「America/Sao_Paulo」や「Asia/Kolkata」のような名前で返します。この名前には、その地域の実際の夏時間のルールがついてきます。そのため、オフセットを直接保存するのではなく、IANA名を保存してそこから現在のオフセットを計算するスケジュールツールは、時計が切り替わっても自動的に正しいままです。ルールは誰かが更新を忘れずに行わなければならない値の中ではなく、タイムゾーンデータベースの中にあるからです。
チームはこれを会議のスケジュールツールに直接組み込みました。そのため、会議の時刻を提案すると、固定の表から引くのではなく、会議を設定するその時点で新たに計算された、すべての参加者の現地時刻が正しく表示されるようになりました。数週間前に提案される会議では、将来の特定の時点のオフセットを計算できるエンドポイントの機能も重要でした。ある地域の時計の切り替え前に設定され、切り替え後に開催される会議には、設定した日に有効だったオフセットではなく、切り替え後の正しいオフセットが必要だったからです。
目に見える変化は、スケジュールのミスが減り、誰かにとって非常識な時刻になってしまった会議についての謝罪のメッセージが減ったことでした。あまり目に見えない変化は、チームの誰もが4か国の夏時間の日程を覚えておく必要がなくなったことです。それ以前は、実際に誰かが非公式に、無償でその役目を担っていました。
この種の解決策は、規模を大きくするのと同じくらい簡単に小さくすることもできます。12人のチームと1,000人の企業が抱える根本的な問題は同じで、違うのは量だけです。検索自体の複雑さはどちらでも変わらず、変わるのは呼び出される頻度だけです。小規模なチームでは、利用量はキーに含まれる1日の無料枠に余裕で収まりました。十数人のタイムゾーンを数回割り出す程度は、1日あたり2,500回利用できる無料リクエストに比べればごくわずかな作業量だからです。
タイムゾーンのバグは、実際に問題を引き起こすまでたいてい目に見えず、気づいたときには会議に参加し損ねたり、顧客を混乱させたりしています。基になるデータソースを一度修正すれば、今後はこの種の誤りがまるごとなくなります。エンドポイントのドキュメントは/docs/timezone-lookup/にあります。