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 repose 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 inférieur est limitée aux appareils de téléphonie.

Lorsque la détection de fuseau horaire de téléphonie est disponible, elle fonctionne à l'aide des 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 antennes relais à 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 pour 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 de fuseau horaire de téléphonie est un détecteur passif . Il fonctionne à tout moment et donc des suggestions de téléphonie sont souvent faites même lorsque l'origine du time_zone_detector n'est pas actuellement la téléphonie.

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

Même avec des signaux NITZ corrects disponibles, la détection de fuseau horaire de téléphonie ne fonctionne pas toujours bien dans tous les pays. En effet, NITZ ne contient que des informations sur le décalage et l'heure d'été, qui ne sont pas toujours suffisantes pour 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 Colorado et Phoenix Arizona aux États-Unis ne peuvent pas être distingués à l'aide des signaux NITZ en hiver, mais peuvent le faire pendant les autres saisons. Tout emplacement dont les fuseaux horaires se chevauchent de la même manière peut rencontrer ce type de problème.

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

Lieu 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 America/Denver.
Phoenix, 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 est mal réglé sur America/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 America/Denver.
Phoenix, 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, ce qui peut être incorrect pour certains appareils mais afficher une heure locale apparemment correcte. L'horloge de l'appareil, les calendriers et les 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 temporairement afficher une heure locale incorrecte s'ils sont définis sur le mauvais ID de fuseau horaire 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 transmettent 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 le débogage et le test de 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 de téléphonie 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'appareil de l'IANA TZDB (règles de fuseau horaire). Les signaux NITZ qui sont incompatibles avec le MCC rendent l'origine de la téléphonie incertaine.

Par exemple, si le MCC utilisé par la cellule de test est pour les États-Unis, le signal NITZ doit contenir une information de "temps universel", de décalage et d'heure d'été correcte pour quelque part aux États-Unis.

Interagir avec le service com.android.phone

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

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

Cela vide les informations de téléphonie, qui peuvent également être trouvées dans les rapports de bogues Android. Sur les appareils avec plusieurs cartes SIM, il y a des informations 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")]}