في الأجهزة التي تعمل بالإصدار 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، بدون توقيت صيفي")، ولكن قد يستغرق ذلك بعض الوقت ويعتمد على مشغّلي شبكات الجوّال.
نتيجةً لذلك، قد تعرض التقاويم أو التطبيقات الأخرى التي تخزِّن رقم تعريف المنطقة الزمنية أو تنقل هذا الرقم من الشتاء إلى الربيع الوقت المحلي غير الصحيح وتستخدمه إلى أن تتم تحديث أرقام تعريف المناطق الزمنية في التطبيقات المعنيّة.
تصحيح الأخطاء والاختبار
يصف القسم التالي أوامر واجهة الأوامر لتصحيح الأخطاء واختبار ميزة رصد المنطقة الزمنية للاتصال الهاتفي.
إعداد بيئة الاختبار
يستخدم المختبِرون عادةً بيئة اختبارية تتضمّن خلية هاتفية اختبارية أو محاكية للتحقّق من سلوك رصد المنطقة الزمنية عبر الهاتف. يمكن استخدام خلية الاختبار لمحاولة محاكاة الشبكات التي تستخدم حسابات موحّدة لإدارة العملاء مختلفة ولإرسال إشارات 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")]}