رصد المنطقة الزمنية من خلال الهاتف

في الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأقدم، يعتمد رصد المنطقة الزمنية التلقائي في AOSP على الإشارات الواردة من النظام الفرعي للهاتف. بسبب الاعتماد على النظام الفرعي للاتصالات الهاتفية، يقتصر رصد المنطقة الزمنية التلقائي على أجهزة الاتصالات الهاتفية في Android 11 أو الإصدارات الأقدم.

عندما تتوفّر ميزة رصد المنطقة الزمنية عبر الهاتف، تعمل باستخدام إشارات رمز البلد الذي يتم فيه تشغيل شبكة الجوّال (MCC) و معرّف الشبكة والمنطقة الزمنية (NITZ).

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

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

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

قيود رصد المنطقة الزمنية عبر الهاتف

حتى في حال توفّر إشارات NITZ الصحيحة، لا تعمل ميزة التعرّف على المنطقة الزمنية عبر الهاتف بشكلٍ جيد في كل البلدان. ويعود السبب في ذلك إلى أنّ تنسيق NITZ لا يحتوي إلا على معلومات التوقيت الزمني و التوقيت الصيفي، وهي معلومات لا تكفي دائمًا لتحديد المنطقة الزمنية بشكل فريد.

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

يوضّح الجدول التالي سلوك الجهاز استنادًا إلى الموسم، ويعرض مثالاً على ذلك في دبي وأبوظبي:

الموقع الجغرافي والموسم معلومات من "مركز عملائي" أو NITZ المنطقة الزمنية والسلوك الذي تم رصده
دنفر، كولورادو
الشتاء
الوقت: 1 كانون الثاني (يناير) 2021 12:00:00
البلد: الولايات المتحدة
التوقيت: التوقيت العالمي المنسق -7، بدون توقيت صيفي
يتطابق رقما تعريف منطقتَين:
  • أمريكا/دنفر
  • أمريكا/فينيكس

تم ضبط الجهاز بشكل صحيح على America/Denver.
فينيكس، أريزونا
الشتاء
الوقت: 1 كانون الثاني (يناير) 2021 12:00:00
البلد: الولايات المتحدة
التوقيت: التوقيت العالمي المنسق -7، بدون توقيت صيفي
يتطابق رقما تعريف منطقتَين:
  • أمريكا/دنفر
  • أمريكا/فينيكس

تم ضبط الجهاز بشكل غير صحيح على America/Denver.
دنفر، كولورادو
الصيف
الوقت: 1 تموز (يوليو) 2021، الساعة 12:00:00
البلد: الولايات المتحدة
التوقيت: التوقيت العالمي المنسق -6، التوقيت الصيفي
يتطابق معرّف منطقة واحد مع:
  • أمريكا/دنفر

تم ضبط الجهاز بشكل صحيح على America/Denver.
فينيكس، أريزونا
سمر
الوقت: 1 تموز (يوليو) 2021، الساعة 12:00:00
البلد: الولايات المتحدة
التوقيت: التوقيت العالمي المنسق -7، بدون توقيت صيفي
يتطابق معرّف منطقة واحد مع:
  • أمريكا/فينيكس

تم ضبط الجهاز بشكل صحيح على America/Phoenix.

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

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

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

تصحيح الأخطاء والاختبار

يصف القسم التالي أوامر shell لتصحيح الأخطاء واختبار ميزة التعرّف على المنطقة الزمنية من خلال الهاتف.

إعداد بيئة الاختبار

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

لكي يرصد الجهاز المنطقة الزمنية، يجب أن تكون معلومات إشارة NITZ صحيحة ومتوافقة مع معيار MCC وأن تتطابق مع نسخة الجهاز من قاعدة بيانات IANA TZDB (قواعد المنطقة الزمنية). تؤدي إشارات NITZ غير المتوافقة مع MCC إلى عدم يقين خوارزمية الهاتف.

على سبيل المثال، إذا كان MCC المستخدَم في خلية الاختبار مخصّصًا للولايات المتحدة، يجب أن تحتوي إشارة NITZ على "الوقت العالمي" والفرق الزمني ومعلومات التوقيت الصيفي التي تكون صحيحة لأحد الأماكن في الولايات المتحدة.

.

التفاعل مع خدمة com.android.phone

للتأكّد من أنّ الجهاز يتلقّى اقتراحات صحيحة للمناطق الزمنية في خدمات الهاتف، استخدِم:

adb shell dumpsys activity service \
    com.android.phone/com.android.phone.TelephonyDebugService

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

تعرض سجلّات المناطق الزمنية الاقتراحات التي أرسلتها عملية الاتصال الهاتفي إلى time_zone_detector وأسباب إرسال الاقتراحات.

TimeServiceHelperImpl:
          SystemClock.elapsedRealtime()=11864061
          System.currentTimeMillis()=1620652067178
          Time Logs:
...

Time zone Logs:
    18602 / 2021-05-10T09:50:21.718Z - Suggesting time zone update:
    TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='null', mMatchType=0, mQuality=0,
    mDebugInfo=[getTimeZoneSuggestion: nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
    countryIsoCode=null, Detection
    reason=handleNitzReceived(TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}})]}
    18831 / 2021-05-10T09:50:21.948Z - Suggesting time zone update:
    TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='Europe/London', mMatchType=3, mQuality=1,
    mDebugInfo=[findTimeZoneFromCountryAndNitz: countryIsoCode=gb,
    nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
    findTimeZoneFromCountryAndNitz: lookupResult=OffsetResult{mTimeZone(ID)=Europe/London,
    mIsOnlyMatch=true}, Detection reason=handleCountryDetected("gb")]}