Rilevamento del fuso orario per la telefonia

Per i dispositivi con Android 11 o versioni precedenti, il rilevamento automatico del fuso orario in AOSP si basa sui segnali 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 è disponibile il rilevamento del fuso orario della telefonia, funziona utilizzando i segnali del codice paese mobile (MCC) e dell'identità di rete e del fuso orario (NITZ).

Ad esempio, un dispositivo in Belgio può identificare il fuso orario in base esclusivamente al MCC segnalato dalle torri cellulari vicine. Ciò è possibile perché il Belgio è noto per utilizzare un unico fuso orario.

Quando un paese utilizza più fusi orari, il solo MCC non è sufficiente per identificare il fuso orario. Per questi paesi, il dispositivo utilizza anche i segnali NITZ per identificare il fuso orario corretto. Questo sistema funziona bene in molte parti del mondo, ma richiede che i segnali NITZ siano disponibili e corretti e dipende quindi dagli operatori.

Il rilevamento del fuso orario della telefonia è un rilevatore passivo. Viene eseguito in qualsiasi momento, quindi i suggerimenti di telefonia vengono spesso forniti anche quando l'algoritmo time_zone_detector attivo non è attualmente la telefonia.

Limitazione del rilevamento del fuso orario della telefonia

Anche con segnali NITZ corretti disponibili, il rilevamento del fuso orario della telefonia non sempre funziona bene in tutti i paesi. Questo perché NITZ contiene solo informazioni su offset e ora legale, che non sono sempre sufficienti per identificare in modo univoco un fuso orario.

Esistono molti luoghi al mondo in cui potrebbe verificarsi questo problema di fuso orario. Ad esempio, Denver, Colorado e Phoenix, Arizona negli Stati Uniti non possono essere distinti utilizzando i segnali 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 mostra il comportamento del dispositivo a seconda della stagione per Denver e Phoenix come esempio:

Gli esempi nella tabella 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 visualizzare comunque un'ora locale apparentemente corretta. L'orologio, i calendari e altre app del dispositivo mostrano l'ora locale prevista anche se l'ID fuso orario è errato, perché entrambi gli ID fuso orario calcolano la stessa ora 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, nessuna ora legale"), ma può richiedere del tempo e dipende dagli operatori.

Di conseguenza, i calendari o altre app che memorizzano o riportano l'ID fuso orario dall'inverno alla primavera potrebbero visualizzare 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 della shell per il debug e il test della funzionalità di rilevamento del fuso orario della telefonia.

Configurazione dell'ambiente di test

I tester in genere utilizzano un ambiente di test con una cella di telefonia di test o simulata per verificare il comportamento di rilevamento del fuso orario della telefonia. La cella di test può essere utilizzata per simulare reti con MCC diversi e per inviare segnali NITZ ai dispositivi e monitorarne gli effetti.

Affinché il dispositivo rilevi il fuso orario, le informazioni sul segnale NITZ devono essere corrette, coerenti con il codice paese e corrispondere alla copia del database TZDB di IANA (regole del fuso orario) del dispositivo. I segnali NITZ incoerenti con il MCC causano incertezza nell'algoritmo di telefonia.

Ad esempio, se il codice paese utilizzato dalla cella di test è per gli Stati Uniti, il segnale NITZ deve contenere informazioni su UTC, offset e ora legale corrette per una località negli Stati Uniti.

Interagire con il servizio com.android.phone

Per verificare che il dispositivo riceva suggerimenti corretti per il fuso orario della telefonia, utilizza:

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

Vengono scaricate le informazioni sulla telefonia, che si trovano anche nei report sui bug di Android. Sui dispositivi con più SIM, sono presenti informazioni per ogni radio SIM.

I log dei fusi orari mostrano i suggerimenti che il processo di telefonia ha inviato a time_zone_detector e i motivi dell'invio.

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