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

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

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

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

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

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

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

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

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

يوضّح الجدول التالي سلوك الجهاز حسب الموسم في دنفر وفينيكس كمثال:

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

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

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

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

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

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

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

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

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

التفاعل مع خدمة 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")]}