En dispositivos que ejecutan Android 11 o versiones anteriores, la detección automática de zona horaria en AOSP se basa en indicadores del subsistema de telefonía. Debido a la dependencia del subsistema de telefonía, la detección automática de zona horaria en Android 11 o versiones anteriores se limita a los dispositivos de telefonía.
Cuando la detección de zona horaria de telefonía está disponible, funciona con los indicadores de código móvil de país (MCC) y identidad de red y zona horaria (NITZ).
Por ejemplo, un dispositivo en Francia puede identificar la zona horaria solo en función del MCC que informan las torres de telefonía celular cercanas. Esto es posible porque se sabe que Francia usa una sola zona horaria.
Cuando un país usa varias zonas horarias, el MCC por sí solo no es suficiente para identificar la zona horaria. En estos países, el dispositivo también usa indicadores NITZ para identificar la zona horaria correcta. Esto funciona bien en muchos lugares del mundo, pero requiere que los indicadores NITZ estén disponibles y sean correctos, por lo que depende de los operadores.
La detección de zona horaria de telefonía es un detector pasivo. Se ejecuta en todo momento, por lo que se suelen realizar sugerencias de telefonía, incluso cuando el algoritmo time_zone_detector activo no es de telefonía.
Limitación de la detección de zona horaria de telefonía
Incluso con los indicadores NITZ correctos disponibles, la detección de zonas horarias de telefonía no siempre funciona bien en todos los países. Esto se debe a que NITZ solo contiene información de desplazamiento y horario de verano, que no siempre es suficiente para identificar de manera única una zona horaria.
Hay muchos lugares en el mundo donde puede ocurrir este problema de zona horaria. Por ejemplo, Denver, Colorado, y Phoenix, Arizona, en EE.UU., no se pueden distinguir con los indicadores NITZ durante el invierno, pero sí durante otras estaciones. Cualquier ubicación con zonas horarias superpuestas de forma similar puede experimentar este tipo de problema.
En la siguiente tabla, se desglosa el comportamiento del dispositivo según la estación para Denver y Phoenix como ejemplo:
| Ubicación y estación | Información de MCC o NITZ | Zona horaria y comportamiento detectados |
|---|---|---|
| Denver, Colorado Invierno |
Hora: 1 de enero de 2021, 12:00:00 País: EE.UU. Desfase: UTC-7, sin horario de verano |
Dos IDs de zona coinciden:
El dispositivo está configurado correctamente en Estados Unidos/Denver. |
| Phoenix, Arizona Invierno |
Hora: 1 de enero de 2021, 12:00:00 País: EE.UU. Desfase: UTC-7, sin horario de verano |
Dos IDs de zona coinciden:
El dispositivo se configuró de manera incorrecta en Estados Unidos/Denver. |
| Denver, Colorado Verano |
Hora: 1 de julio de 2021 12:00:00 País: EE.UU. Desfase: UTC-6, horario de verano |
El ID de una zona coincide con lo siguiente:
El dispositivo está configurado correctamente en Estados Unidos/Denver. |
| Phoenix, Arizona Verano |
Hora: 1 de julio de 2021, 12:00:00 País: EE.UU. Desfase: UTC-7, sin horario de verano |
Un ID de zona coincide con lo siguiente:
El dispositivo está configurado correctamente en América/Phoenix. |
En los ejemplos anteriores, se muestra que, durante el invierno, los dispositivos Android en Denver o Arizona deben elegir uno de los dos IDs de zona horaria coincidentes, que pueden ser incorrectos para algunos dispositivos, pero que aún muestran una hora local aparentemente correcta. El reloj del dispositivo, los calendarios y otras apps muestran la hora local esperada, incluso si el ID de zona horaria es incorrecto, ya que ambos IDs de zona horaria calculan la misma hora local durante el invierno.
Sin embargo, en la primavera, cuando Denver observa el horario de verano y Phoenix no, es posible que algunos dispositivos muestren temporalmente la hora local incorrecta si están configurados con el ID de zona horaria incorrecto para la ubicación del usuario. Esto se corrige en cuanto el dispositivo recibe una nueva señal NITZ (específicamente, una que contiene información de compensación "UTC-7, sin horario de verano"), pero esto puede tardar un poco y depende de los operadores.
Como resultado, los calendarios y otras apps que almacenan o transfieren el ID de zona horaria de invierno a primavera pueden mostrar y usar una hora local incorrecta hasta que las apps relevantes actualicen el ID de zona horaria.
Depuración y pruebas
En la siguiente sección, se describen los comandos de shell para depurar y probar la función de detección de zona horaria de telefonía.
Configuración del entorno de pruebas
Por lo general, los verificadores usan un entorno de pruebas con una celda de telefonía simulada o de prueba para verificar el comportamiento de detección de la zona horaria de telefonía. La celda de prueba se puede usar para simular redes con diferentes MCC y enviar indicadores NITZ a los dispositivos y, luego, supervisar sus efectos.
Para que el dispositivo detecte la zona horaria, la información de la señal NITZ debe ser correcta, coherente con el MCC y coincidir con la copia del dispositivo de la IANA TZDB (reglas de zona horaria). Los indicadores NITZ que no son coherentes con el MCC hacen que el algoritmo de telefonía sea incierto.
Por ejemplo, si el MCC que usa la celda de prueba es para EE.UU., el indicador NITZ debe contener información de "hora universal", desfase y de horario de verano que sea correcta para algún lugar de los EE.UU.
Interactuar con el servicio com.android.phone
Para verificar que el dispositivo reciba sugerencias de zonas horarias de telefonía correctas, usa lo siguiente:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Esto volcará información de telefonía, que también se puede encontrar en los informes de errores de Android. En los dispositivos con varias SIM, hay información para cada radio SIM.
Los registros de zona horaria muestran las sugerencias que el proceso de telefonía envió al detector de zona horaria y los motivos por los que se enviaron.
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")]}