الأدلة

إنشاء أداة لاختيار المنطقة الزمنية تعتمد افتراضيًا منطقة الزائر

التمرير عبر قائمة بأسماء المناطق الزمنية للعثور على منطقتكم إزعاج صغير تزيله قيمة افتراضية معقولة لدى الجميع تقريبًا.

اكتشاف المنطقة

تعيد نقطة النهاية /v1/ip حقل timezone مباشرة، لذا يمنحكم استدعاء واحد الموقع ومعرّف المنطقة الزمنية معًا، دون استدعاء منفصل لنقطة نهاية المنطقة الزمنية.

GET /v1/ip?ip=203.0.113.88
{
  "status": "ok",
  "ip": "203.0.113.88",
  "version": 4,
  "found": true,
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "postcode": "2000",
  "lat": -33.8688,
  "lon": 151.2093,
  "timezone": "Australia/Sydney",
  "asn": 7890,
  "org": "Example Networks"
}

التحديد المسبق في أداة الاختيار

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

مثال ثانٍ: عدة أشخاص في حجز واحد

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

السماح للزائر بتغييرها

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

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

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

الاكتشاف مرة واحدة، لا في كل زيارة

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

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

كم يكلف

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

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