اعرض ساعات العمل الصحيحة بناءً على موقع الزائر

عبارة "نحن مفتوحون حتى الساعة 6 مساءً" لا تفيد إلا إذا عرف الزائر الذي يقرؤها أي ساعة 6 مساءً تقصد. فالزائر الموجود في منطقة زمنية مختلفة عن منطقة نشاطك التجاري يحتاج إلى أن تُجرى هذه المقارنة بتوقيته المحلي، لا بتوقيتك.

الحصول على المنطقة الزمنية للزائر

استعلام IP واحد يعيد حقل timezone مباشرة، فيمنحك ما تحتاجه دون استدعاء منفصل.

GET /v1/ip?ip=203.0.113.44

{
  "status": "ok",
  "ip": "203.0.113.44",
  "version": 4,
  "found": true,
  "country": "Japan",
  "country_code": "JP",
  "region": "Tokyo",
  "city": "Tokyo",
  "postcode": "100-0001",
  "lat": 35.6762,
  "lon": 139.6503,
  "timezone": "Asia/Tokyo",
  "asn": 2345,
  "org": "Example Telecom"
}

المقارنة مع ساعات عملك

حوّل ساعات عملك، المخزنة وفق المنطقة الزمنية لنشاطك التجاري، إلى منطقة الزائر باستخدام معرّف المنطقة الزمنية الذي حصلت عليه للتو، ثم قارنها بالتوقيت المحلي الحالي للزائر لتقرر ما إذا كنت ستعرض "مفتوح الآن" أو "مغلق"، إلى جانب التوقيت المحلي الذي تستند إليه في هذا العرض.

مثال ثانٍ: نشاط تجاري له أكثر من فرع

النشاط التجاري الذي له فروع في مدن مختلفة ينبغي أن يأخذ ساعات العمل المعلنة لكل فرع وفق منطقته الزمنية المخزنة، ثم يقارن كلًا منها على حدة بمنطقة الزائر، بدلًا من افتراض أن مجموعة واحدة من الساعات تنطبق في كل مكان. ويهم هذا أكثر ما يهم حين يقارن الزائر بين فرعين في الصفحة نفسها، إذ قد يظهر أحدهما مفتوحًا والآخر مغلقًا في اللحظة نفسها تمامًا إذا كانا في منطقتين زمنيتين مختلفتين أو يطبقان التوقيت الصيفي بشكل مختلف.

التصريح بالمنطقة الزمنية التي تقصدها

بدلًا من التحويل بصمت والأمل في أن يفهم الزائر، اعرض المعلومتين بوضوح، بصيغة مثل "مغلق حاليًا. يفتح الساعة 9 صباحًا بتوقيتك (Asia/Tokyo)." فالتصريح يمنع الارتباك حين يعمل النشاط التجاري عبر حدود يتغير فيها التوقيت الصيفي على جانب دون الآخر.

خطأ شائع يجب تجنبه

لا تحسب مقارنة الفتح أو الإغلاق مرة واحدة ثم تخزن تلك القيمة المنطقية مؤقتًا طوال بقية جلسة الزائر. فالمقارنة التي تُجرى الساعة 5:55 مساءً ستظهر "مفتوح" وتبقى خاطئة بحلول الساعة 6:05 مساءً إذا خُزنت حالة الفتح مؤقتًا بدلًا من إعادة حسابها. خزّن معرّف المنطقة الزمنية للزائر مؤقتًا، لأنه ثابت فعلًا طوال الجلسة، لكن أعد حساب مقارنة الفتح أو الإغلاق الفعلية من جديد عند كل عرض.

حالة حدّية: مناطق لا تطبق التوقيت الصيفي

بعض المناطق تحافظ على فارق توقيت ثابت طوال العام بينما تغيّر منطقة مجاورة توقيتها مرتين في السنة، ما يعني أن الفرق بين المنطقتين ليس ثابتًا على مدار التقويم. وإذا كان منطق المقارنة لديك يثبّت فارقًا بالساعات في الشيفرة بدلًا من العمل انطلاقًا من معرّف المنطقة الزمنية وترك مكتبة التواريخ تتولى التحويل، فسيخرج عن التزامن تحديدًا في الأسابيع المحيطة بتغيير التوقيت الصيفي.

خزّن المنطقة الزمنية مؤقتًا، لا حالة الفتح

معرّف المنطقة الزمنية للزائر ثابت طوال الجلسة ويستحق التخزين المؤقت. أما كون النشاط التجاري مفتوحًا حاليًا فيتغير على مدار اليوم، لذا أعد حساب تلك المقارنة وقت العرض باستخدام المنطقة المخزنة مؤقتًا بدلًا من تخزين حالة الفتح أو الإغلاق نفسها.

التحقق من لحظة محددة في الماضي أو المستقبل

إذا احتجت إلى معرفة ما كان عليه فارق التوقيت، أو ما سيكون عليه، في لحظة محددة لا في اللحظة الحالية، مثل التأكد من الوقت الفعلي لطلب شراء قُدم أمس في منطقة العميل الزمنية، فإن ⁦/v1/timezone⁩ تقبل معلمة time اختيارية على شكل طابع زمني يونكس لهذا النوع تحديدًا من التحقق التاريخي أو المستقبلي.

تكلفة الطلبات

استعلام IP واحد لكل جلسة زائر جديدة يغطي هذه الميزة. أي طلب واحد يُخزن مؤقتًا طوال مدة الزيارة، ما يبقي حتى متجرًا إلكترونيًا مزدحمًا ضمن 2,500 طلب مجاني يوميًا المضمنة مع كل مفتاح بهامش مريح.

عرض "مفتوح الآن" بشكل صحيح لجمهور عالمي مسألة استعلام واحد ومقارنة زمنية مباشرة، لا ميزة معقدة. ويسرد توثيق الاستعلام عن IPv4 الشكل الكامل للاستجابة.