上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
サーバーのタイムゾーンで表示されたタイムスタンプを正しく読めるのは、たまたま同じタイムゾーンにいる人だけです。世界中から訪問者が来るサイトにとって、それはほとんど誰もいないのと同じです。
IP検索はtimezoneフィールドを直接返すため、ページ上のあらゆるタイムスタンプのローカライズに必要な識別子が得られます。
GET /v1/ip?ip=203.0.113.77{
"status": "ok",
"ip": "203.0.113.77",
"version": 4,
"found": true,
"country": "Brazil",
"country_code": "BR",
"region": "Rio de Janeiro",
"city": "Rio de Janeiro",
"postcode": "20040",
"lat": -22.9068,
"lon": -43.1729,
"timezone": "America/Sao_Paulo",
"asn": 5566,
"org": "Example ISP"
}データベースにはいつもどおりすべてのタイムスタンプをUTCで保存し、表示する時点でのみ、検索したタイムゾーン識別子を使って、サーバー側で訪問者のローカルタイムゾーンに変換します。このサイトはクライアント側のJavaScriptを使わず、すべてをサーバー側でレンダリングしているため、変換と書式設定はどちらも、ブラウザで後から行われるのではなく、ページが送信される前に行われます。
local_time = convert_to_timezone(stored_utc_timestamp, "America/Sao_Paulo")「注文日時」と「お届け予定日時」を表示する注文確認ページは、単純なページヘッダーの時計以外でもこれが重要になる好例です。うっかり一方をサーバー時刻のまま残すのではなく、両方のタイムスタンプを同じ訪問者のタイムゾーンで変換すれば、2つの数値の一貫性が保たれます。一方だけが変換されたせいで、お届け予定時刻が注文時刻より前に見えてしまうような、紛らわしい状況も避けられます。
タイムゾーンと書式は関連していますが、別々の選択です。24時間制の時計と日・月・年の日付順がよく使われる地域の訪問者には、時刻の値をずらしただけで見慣れない書式のままにするのではなく、それに合った書式が役立ちます。時刻の調整だけにとどまらず対応したい場合は、同じIP検索で得られるcountry_codeを、小さな書式設定用の対応表と組み合わせてください。
変換を、一度だけ計算して以後すべてのタイムスタンプに適用する固定の時差として実装しないでください。タイムゾーンのUTCからの実際のオフセットは、夏時間によって1年の間に変わることがあります。そのため、適切な日付・時刻ライブラリを使ってタイムゾーン識別子そのもので変換するのではなく、保存したオフセットの数値を適用するコードでは、ある季節に正しく変換されたタイムスタンプが、別の季節には1時間ずれてしまうことがあります。
すべてのタイムゾーンがUTCから1時間単位のオフセットにあるわけではありません。1時間ではなく30分や45分ずれているものもあります。簡略化された時間単位のみのオフセット値ではなく、完全なIANAタイムゾーン識別子を理解する日付ライブラリに頼れば、特別な処理のコードを書かなくてもこれを正しく扱えます。変換した時刻と並べてオフセットを明示的に表示したい場合は、タイムゾーン検索のドキュメントにあるutc_offsetとabbreviationのフィールドが役立ちます。
表示する日付ごとにAPIを呼び出し直すのではなく、訪問者のセッションごとに1回だけタイムゾーンを検索し、その訪問中にすべてのページで表示されるすべてのタイムスタンプに再利用してください。セッションの途中でタイムゾーン自体が変わることはないからです。
新しいセッションごとに1回の検索で、その訪問中に表示されるすべてのタイムスタンプのローカライズをカバーできます。ページにいくつ日付が表示されても、リクエストは1件です。これにより、コンテンツの多いサイトでも、すべてのキーに含まれる1日あたり2,500件の無料リクエストの範囲に十分収まります。
サイト全体でローカルの日付と時刻の書式を正しく扱うには、セッションごとに1回の検索と、その後の一貫したサーバー側のレンダリングがあれば十分です。IPv4検索のドキュメントとタイムゾーン検索のドキュメントで、タイムゾーンを取得する両方の方法を説明しています。