راقب استخدام مفتاحك قبل أن تبلغ الحد
متابعة ترويسات الحصة أولًا بأول تخبرك متى يقترب الحد، قبل وقت طويل من رفض أي طلب فعليًا.
اعرض صيغ التاريخ والوقت محليًا باستخدام المنطقة الزمنية للزائر
الطابع الزمني المعروض بالمنطقة الزمنية لخادمك لا يُقرأ بشكل صحيح لأحد تقريبًا سوى من يصادف وجوده في المنطقة نفسها، وهو ما يعني، في موقع يزوره أشخاص من أي مكان، لا أحد تقريبًا على الإطلاق.
الحصول على المنطقة الزمنية للزائر
يعيد البحث عن 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")مثال ثانٍ: الطابع الزمني لتأكيد الطلب
صفحة تأكيد الطلب التي تعرض وقتي "تم الطلب في" و"متوقع بحلول" مثال جيد على المواضع التي يهم فيها هذا الأمر أبعد من مجرد ساعة بسيطة في رأس الصفحة. فتحويل الطابعين الزمنيين كليهما عبر منطقة الزائر نفسها، بدلًا من ترك أحدهما بتوقيت الخادم سهوًا، يحافظ على اتساق القيمتين ويتجنب موقفًا مربكًا يبدو فيه وقت التسليم المتوقع أسبق من وقت الطلب لأن أحدهما حُوِّل والآخر لم يُحوَّل.
التنسيق، لا التحويل فقط
المنطقة الزمنية والتنسيق خياران مترابطان لكنهما منفصلان. فالزائر في منطقة تستخدم عادةً نظام 24 ساعة وترتيب التاريخ يوم ثم شهر ثم سنة يستفيد من تنسيق يطابق ذلك، لا من مجرد قيمة ساعة مُزاحة مكتوبة بتنسيق لا يزال يبدو غريبًا عليه. اربط حقل country_code من البحث نفسه عن IP بجدول تنسيق صغير إذا أردت تجاوز مجرد تعديل الساعة.
خطأ شائع يجب تجنبه
لا تنفّذ التحويل كفارق ساعات ثابت يُحسب مرة واحدة ويُطبَّق على كل طابع زمني من الآن فصاعدًا. فالفارق الفعلي لمنطقة ما عن UTC قد يتغير على مدار السنة مع التوقيت الصيفي، لذا فإن الطابع الزمني الذي حُوِّل بشكل صحيح في موسم ما قد يخرج خاطئًا بساعة في موسم آخر إذا طبّقت الشيفرة رقم فارق مخزنًا بدلًا من التحويل عبر معرّف المنطقة الزمنية نفسه باستخدام مكتبة تاريخ ووقت مناسبة.
حالة استثنائية: فوارق ليست بساعات كاملة
ليست كل منطقة زمنية على فارق بساعات كاملة عن UTC. فبعضها يبتعد بمقدار 30 أو 45 دقيقة بدلًا من ساعة كاملة. والاعتماد على مكتبة تاريخ تفهم معرّف المنطقة الزمنية IANA الكامل، بدلًا من قيمة فارق مبسطة بالساعات فقط، يعالج هذا بشكل صحيح دون أي شيفرة لحالات خاصة من جانبك. وحقلا utc_offset وabbreviation الموضحان في توثيق البحث عن المنطقة الزمنية مفيدان إذا أردت عرض الفارق صراحةً بجانب الوقت المحوَّل.
تخزين المنطقة مؤقتًا طوال الجلسة
ابحث عن المنطقة الزمنية مرة واحدة لكل جلسة زائر وأعد استخدامها لكل طابع زمني يُعرض في كل صفحة خلال تلك الزيارة، بدلًا من استدعاء API مجددًا لكل تاريخ يُعرض على حدة، لأن المنطقة نفسها لا تتغير في منتصف الجلسة.
تكلفة توطين موقع كامل
بحث واحد لكل جلسة جديدة يغطي توطين كل طابع زمني يُعرض خلال تلك الزيارة، أي طلب واحد بغض النظر عن عدد التواريخ الظاهرة في الصفحة. وهذا يُبقي حتى الموقع الغني بالمحتوى ضمن 2,500 طلب مجاني يوميًا المضمنة مع كل مفتاح بهامش مريح.
ضبط تنسيق الوقت والتاريخ المحليين بشكل صحيح في موقع كامل يعود إلى بحث واحد لكل جلسة وعرض متسق على الخادم بعد ذلك. ويغطي توثيق البحث عن IPv4 وتوثيق البحث عن المنطقة الزمنية كلتا الطريقتين للحصول على المنطقة.