Per i dispositivi con Android 11 o versioni precedenti, il rilevamento automatico del fuso orario in AOSP si basa su indicatori del sottosistema di telefonia. A causa della dipendenza dal sottosistema di telefonia, il rilevamento automatico del fuso orario su Android 11 o versioni precedenti è limitato ai dispositivi di telefonia.
Quando il rilevamento del fuso orario per la telefonia è disponibile, funziona utilizzando i segnali Mobile Country Code (MCC) e Network Identity and Time Zone (NITZ).
Ad esempio, un dispositivo in Francia può identificare il fuso orario in base esclusivamente al codice MCC segnalato dalle torri di telefonia mobile nelle vicinanze. Questo è possibile perché la Francia è nota per utilizzare un unico fuso orario.
Quando un paese utilizza più fusi orari, il solo Centro clienti non è sufficiente per identificarli. Per questi paesi, il dispositivo utilizza anche segnali NITZ per identificare il fuso orario corretto. Questo approccio funziona bene in molti paesi in tutto il mondo, ma richiede che i segnali NITZ siano disponibili e corretti, pertanto dipende dagli operatori.
Il rilevamento del fuso orario della telefonia è un rilevatore passivo. Viene eseguito in qualsiasi momento, pertanto i suggerimenti per le chiamate vengono spesso forniti anche quando l'algoritmo time_zone_detector attivo non è attualmente per le chiamate.
Limitazione del rilevamento del fuso orario per la telefonia
Anche se sono disponibili indicatori NITZ corretti, il rilevamento del fuso orario per la telefonia non funziona sempre bene in ogni paese. Questo perché NITZ contiene solo informazioni su offset e ora legale, che non sono sempre sufficienti per identificare in modo univoco un fuso orario.
Questo problema con il fuso orario può verificarsi in molti luoghi del mondo. Ad esempio, Denver in Colorado e Phoenix in Arizona negli Stati Uniti non possono essere distinta utilizzando gli indicatori NITZ durante l'inverno, ma possono esserlo durante le altre stagioni. Qualsiasi località con fusi orari sovrapposti in modo simile potrebbe riscontrare questo tipo di problema.
La tabella seguente illustra il comportamento del dispositivo in base alla stagione per Denver e Phoenix come esempio:
| Località e stagione | Informazioni da MCC o NITZ | Fuso orario e comportamento rilevati |
|---|---|---|
| Denver, Colorado Inverno |
Ora: 1° gennaio 2021 00:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna ora legale |
Corrispondenza di due ID zona:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona Inverno |
Ora: 1° gennaio 2021 00:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna ora legale |
Corrispondenza di due ID zona:
Il dispositivo è impostato erroneamente su America/Denver. |
| Denver, Colorado Estate |
Ora: 1° luglio 2021 12:00:00 Paese: Stati Uniti Differenza di fuso orario: UTC-6, ora legale |
Un ID zona corrisponde:
Il dispositivo è impostato correttamente su America/Denver. |
| Phoenix, Arizona Estate |
Ora: 1° luglio 2021 12:00:00 Paese: Stati Uniti Offset: UTC-7, nessuna ora legale |
Un ID zona corrisponde:
Il dispositivo è impostato correttamente su America/Phoenix. |
Gli esempi riportati sopra mostrano che durante l'inverno i dispositivi Android a Denver o in Arizona devono scegliere uno dei due ID fuso orario corrispondenti, che potrebbe essere errato per alcuni dispositivi, ma che mostra comunque un'ora locale apparentemente corretta. Per l'orologio del dispositivo, i calendari e le altre app viene visualizzato l'ora locale prevista anche se l'ID del fuso orario non è corretto perché entrambi gli ID del fuso orario calcolano lo stesso orario locale durante l'inverno.
Tuttavia, in primavera, quando Denver osserva l'ora legale e Phoenix no, alcuni dispositivi potrebbero mostrare temporaneamente l'ora locale errata se sono impostati sull'ID fuso orario sbagliato per la posizione dell'utente. Questo problema viene corretto non appena il dispositivo riceve un nuovo segnale NITZ (in particolare, uno che contiene informazioni sull'offset "UTC-7, no daylight savings"), ma l'operazione può richiedere del tempo e dipende dagli operatori.
Di conseguenza, i calendari o altre app che memorizzano o trasferiscono l'ID fuso orario dall'inverno alla primavera potrebbero mostrare e utilizzare l'ora locale errata finché le app pertinenti non aggiornano l'ID fuso orario.
Debug e test
La sezione seguente descrive i comandi shell per il debug e il test della funzionalità di rilevamento del fuso orario per la telefonia.
Configurazione dell'ambiente di test
In genere, i tester utilizzano un ambiente di test con una cella telefonica di prova o simulata per verificare il comportamento del rilevamento del fuso orario per la telefonia. La cella di test può essere utilizzata per simulare reti con MCC diverse e per inviare segnali NITZ ai dispositivi e poi monitorarne gli effetti.
Affinché il dispositivo rilevi il fuso orario, le informazioni sul segnale NITZ devono essere corrette, coerenti con il MCC e corrispondere alla copia del dispositivo del database IANA TZDB (regole per i fusi orari). Gli indicatori NITZ incoerenti con il Centro clienti rendono incerto l'algoritmo di telefonia.
Ad esempio, se il Centro clienti utilizzato dalla cella di test è per gli Stati Uniti, il segnale NITZ deve contenere informazioni su "ora universale", offset e ora legale che siano corrette per qualche parte degli Stati Uniti.
Interagire con il servizio com.android.phone
Per verificare che il dispositivo riceva suggerimenti per i fusi orari di telefonia corretti, utilizza:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Vengono scaricate le informazioni di telefonia, che possono essere trovate anche nei report di bug Android. Sui dispositivi con più SIM, sono disponibili informazioni per ogni radio SIM.
I log del fuso orario mostrano i suggerimenti inviati dal processo di telefonia al detector del fuso orario e i motivi per cui sono stati inviati.
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")]}