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

Pour les appareils équipés d'Android 11 ou 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 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 à l'aide du code de pays de la station mobile (MCC) et des signaux Network Identity and Time Zone (NITZ).

Par exemple, un appareil situé en Belgique peut identifier le fuseau horaire en se basant uniquement sur le code MCC indiqué par les antennes-relais à proximité. Cela est possible, car la Belgique est connue pour utiliser un seul fuseau horaire.

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

La détection du fuseau horaire de la téléphonie est un détecteur passif. Il s'exécute en permanence. Les suggestions de téléphonie sont donc souvent faites même lorsque l'algorithme time_zone_detector actif n'est pas actuellement la téléphonie.

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

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

Ce problème de fuseau horaire peut se produire dans de nombreux endroits du monde. Par exemple, il est impossible de distinguer Denver (Colorado) et Phoenix (Arizona) aux États-Unis à l'aide des signaux NITZ en hiver, mais c'est possible pendant les autres saisons. Tout lieu dont les fuseaux horaires se chevauchent de manière similaire peut être concerné par ce type de problème.

Le tableau suivant décrit le comportement de l'appareil en fonction de la saison pour Denver et Phoenix, par exemple :

Lieu et saison Informations provenant du code 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 :
  • America/Denver
  • America/Phoenix

L'appareil est correctement défini 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 :
  • America/Denver
  • America/Phoenix

L'appareil est incorrectement défini 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 :
  • America/Denver

L'appareil est correctement défini 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 :
  • America/Phoenix

L'appareil est correctement défini sur "America/Phoenix".

Les exemples du tableau montrent que pendant l'hiver, les appareils Android situés à Denver ou en Arizona doivent choisir l'un des deux ID de fuseau horaire correspondants, qui peuvent être incorrects pour certains appareils, mais qui affichent tout de même une heure locale apparemment correcte. L'horloge, les calendriers et d'autres applications de l'appareil affichent l'heure locale attendue, même si l'ID du fuseau horaire est incorrect, car les deux ID de fuseau horaire calculent la même heure locale en hiver.

Toutefois, au printemps, lorsque Denver passe à l'heure d'été et que Phoenix ne le fait pas, certains appareils peuvent afficher temporairement l'heure locale incorrecte s'ils sont définis sur le mauvais ID de fuseau horaire pour l'emplacement de l'utilisateur. Ce problème est corrigé dès que l'appareil reçoit un nouveau signal NITZ (plus précisément, un signal contenant 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 du 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 du fuseau horaire.

Débogage et test

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

Configurer l'environnement de test

Les testeurs utilisent généralement un environnement de test avec une cellule de téléphonie 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 code MCC et correspondre à la copie TZDB (base de données de fuseaux horaires) de l'IANA de l'appareil. Les signaux NITZ qui ne sont pas cohérents avec le code MCC entraînent une incertitude de l'algorithme de téléphonie.

Par exemple, si le code pays utilisé par la cellule de test est celui des États-Unis, le signal NITZ doit contenir des informations sur l'heure UTC, le décalage et l'heure d'été qui sont correctes pour un lieu 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 permet de vider les informations de téléphonie, qui sont également disponibles dans les rapports de bug Android. Sur les appareils équipés de plusieurs cartes SIM, des informations sont disponibles pour chaque module radio SIM.

Les journaux du fuseau horaire affichent les suggestions que le processus de téléphonie a envoyées au time_zone_detector, ainsi que les raisons de l'envoi de ces 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")]}