Détection de fuseau horaire de téléphonie

Pour les appareils exécutant Android 11 ou une version antérieure, la détection automatique du fuseau horaire dans l'AOSP s'appuie sur les signaux du sous-système de téléphonie. En raison de la dépendance au sous-système de téléphonie, la détection automatique du fuseau horaire sur Android 11 ou version antérieure est limitée aux appareils de téléphonie.

Lorsque la détection du fuseau horaire de la téléphonie est disponible, elle fonctionne en utilisant les signaux Mobile Country Code (MCC) et Network Identity and Time Zone (NITZ) .

Par exemple, un appareil en France peut identifier le fuseau horaire en se basant uniquement sur le MCC signalé par les tours de téléphonie cellulaire à proximité. Cela est possible car la France est connue pour utiliser un seul fuseau horaire.

Lorsqu'un pays utilise plusieurs fuseaux horaires, le MCC seul ne suffit pas à identifier le fuseau horaire. Pour ces pays, l'appareil utilise également les signaux NITZ pour identifier le fuseau horaire correct. Cela fonctionne bien dans de nombreux endroits du monde, mais cela nécessite que les signaux NITZ soient à la fois disponibles et corrects et cela dépend donc des opérateurs.

La détection du fuseau horaire de la téléphonie est un détecteur passif . Il fonctionne à tout moment et des suggestions de téléphonie sont donc souvent faites même lorsque l'algorithme time_zone_detector actif n'est pas actuellement une téléphonie.

Limitation de la détection du fuseau horaire de la téléphonie

Même avec des signaux NITZ corrects disponibles, la détection du fuseau horaire de la téléphonie ne fonctionne pas toujours correctement dans tous les pays. En effet, NITZ ne contient que des informations de décalage et d'heure d'été, qui ne suffisent pas toujours à identifier de manière unique un fuseau horaire.

Il existe de nombreux endroits dans le monde où ce problème de fuseau horaire peut survenir. Par exemple, Denver au Colorado et Phoenix en Arizona aux États-Unis ne peuvent pas être distingués à l'aide des signaux NITZ en hiver, mais cela peut être le cas pendant d'autres saisons. Tout endroit dont les fuseaux horaires se chevauchent de manière similaire peut rencontrer ce type de problème.

Le tableau suivant détaille le comportement de l'appareil en fonction de la saison pour Denver et Phoenix à titre d'exemple :

Localisation et saison Informations du MCC ou du NITZ Fuseau horaire et comportement détectés
Denver, Colorado
Hiver
Heure : 1er janvier 2021 12:00:00
Pays : États-Unis
Décalage : UTC-7, pas d'heure d'été
Deux ID de zone correspondent :
  • Amérique/Denver
  • Amérique/Phœnix

L'appareil est correctement réglé sur Amérique/Denver.
Phénix, Arizona
Hiver
Heure : 1er janvier 2021 12:00:00
Pays : États-Unis
Décalage : UTC-7, pas d'heure d'été
Deux ID de zone correspondent :
  • Amérique/Denver
  • Amérique/Phœnix

L'appareil n'est pas correctement réglé sur Amérique/Denver.
Denver, Colorado
Été
Heure : 1er juillet 2021 12:00:00
Pays : États-Unis
Décalage : UTC-6, heure d'été
Un ID de zone correspond :
  • Amérique/Denver

L'appareil est correctement réglé sur Amérique/Denver.
Phénix, Arizona
Été
Heure : 1er juillet 2021 12:00:00
Pays : États-Unis
Décalage : UTC-7, pas d'heure d'été
Un ID de zone correspond :
  • Amérique/Phœnix

L'appareil est correctement réglé sur America/Phoenix.

Les exemples ci-dessus montrent qu'en hiver, les appareils Android à Denver ou en Arizona doivent choisir l'un des deux identifiants de fuseau horaire correspondants, qui peuvent être incorrects pour certains appareils mais affichent toujours une heure locale apparemment correcte. L'horloge de l'appareil, les calendriers et autres applications affichent l'heure locale prévue même si l'ID de fuseau horaire est incorrect, car les deux ID de fuseau horaire calculent la même heure locale en hiver.

Cependant, au printemps, lorsque Denver observe l'heure d'été et que Phoenix ne le fait pas, certains appareils peuvent afficher temporairement une heure locale incorrecte s'ils sont réglés sur un identifiant de fuseau horaire incorrect pour l'emplacement de l'utilisateur. Ceci est corrigé dès que l'appareil reçoit un nouveau signal NITZ (en particulier, celui qui contient des informations de décalage « UTC-7, pas d'heure d'été »), mais cela peut prendre un certain temps et dépend des opérateurs.

Par conséquent, les calendriers ou autres applications qui stockent ou reportent l’ID de fuseau horaire de l’hiver au printemps peuvent afficher et utiliser la mauvaise heure locale jusqu’à ce que les applications concernées mettent à jour l’ID de fuseau horaire.

Débogage et tests

La section suivante décrit les commandes shell pour déboguer et tester la fonctionnalité de détection de fuseau horaire de téléphonie.

Configuration de l'environnement de test

Les testeurs utilisent généralement un environnement de test avec une cellule téléphonique de test ou simulée pour vérifier le comportement de détection du fuseau horaire de la téléphonie. La cellule de test peut être utilisée pour simuler des réseaux avec différents MCC et pour envoyer des signaux NITZ aux appareils, puis surveiller leurs effets.

Pour que l'appareil détecte le fuseau horaire, les informations du signal NITZ doivent être correctes, cohérentes avec le MCC et correspondre à la copie de l'IANA TZDB (règles de fuseau horaire) de l'appareil. Les signaux NITZ incompatibles avec le MCC rendent l'algorithme de téléphonie incertain.

Par exemple, si le MCC utilisé par la cellule de test est destiné aux États-Unis, le signal NITZ doit contenir un « heure universelle », un décalage et des informations sur l'heure d'été qui sont correctes quelque part aux États-Unis.

Interagir avec le service com.android.phone

Pour vérifier que l'appareil reçoit les suggestions de fuseau horaire de téléphonie correctes, utilisez :

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

Cela supprime les informations de téléphonie, qui peuvent également être trouvées dans les rapports de bogues Android. Sur les appareils dotés de plusieurs cartes SIM, des informations sont disponibles pour chaque radio SIM.

Les journaux de fuseau horaire affichent les suggestions que le processus de téléphonie a envoyées au time_zone_detector et les raisons de l'envoi des suggestions.

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")]}