En dispositivos que ejecutan Android 11 o versiones anteriores, la detección automática de zona horaria en el AOSP se basa en los 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 el código móvil de país (MCC) y los indicadores de identidad de red y zona horaria (NITZ).
Por ejemplo, un dispositivo en Bélgica puede identificar la zona horaria basándose únicamente en el MCC que informan las torres de telefonía celular cercanas. Esto es posible porque se sabe que Bélgica 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 de NITZ para identificar la zona horaria correcta. Esto funciona bien en muchos lugares del mundo, pero requiere que los indicadores de 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 las sugerencias de telefonía a menudo se realizan incluso cuando el algoritmo de time_zone_detector
activo no es de telefonía en ese momento.
Limitación de la detección de zona horaria por telefonía
Incluso con los indicadores NITZ correctos disponibles, la detección de la zona horaria de telefonía no siempre funciona bien en todos los países. Esto se debe a que la NITZ solo contiene información sobre el desplazamiento y el horario de verano, que no siempre son suficientes para identificar de forma única una zona horaria.
Hay muchos lugares en el mundo donde podría ocurrir este problema de zona horaria. Por ejemplo, Denver, Colorado y Phoenix, Arizona, en EE.UU., no se pueden distinguir con los indicadores de NITZ durante el invierno, pero sí en otras estaciones. Cualquier ubicación con zonas horarias que se superpongan de manera similar puede experimentar este tipo de problema.
En la siguiente tabla, se desglosa el comportamiento del dispositivo según la temporada para Denver y Phoenix como ejemplo:
Ubicación y temporada | Información del MCC o del NITZ | Zona horaria y comportamiento detectados |
---|---|---|
Denver, Colorado Invierno |
Fecha y hora: 1 de enero de 2021, 12:00:00 País: EE.UU. Desplazamiento: UTC-7, sin horario de verano |
Coinciden dos IDs de zona:
El dispositivo está configurado correctamente en America/Denver. |
Phoenix, Arizona Invierno |
Fecha y hora: 1 de enero de 2021, 12:00:00 País: EE.UU. Desplazamiento: UTC-7, sin horario de verano |
Coinciden dos IDs de zona:
El dispositivo está configurado de forma incorrecta en America/Denver. |
Denver, Colorado Verano |
Fecha y hora: 1 de julio de 2021, 12:00:00 País: EE.UU. Desplazamiento: UTC-6, horario de verano |
Coincide con un ID de zona:
El dispositivo está configurado correctamente en America/Denver. |
Phoenix, Arizona Verano |
Fecha y hora: 1 de julio de 2021, 12:00:00 País: EE.UU. Desplazamiento: UTC-7, sin horario de verano |
Coincide con un ID de zona:
El dispositivo está configurado correctamente en America/Phoenix. |
Los ejemplos de la tabla muestran que, durante el invierno, los dispositivos Android de Denver o Arizona deben elegir uno de los dos IDs de zona horaria coincidentes, que podría ser incorrecto para algunos dispositivos, pero que aún muestra 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 calculan la misma hora local durante el invierno.
Sin embargo, en 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 de NITZ (específicamente, una que contiene información de desplazamiento "UTC-7, sin horario de verano"), pero esto puede llevar algún tiempo y depende de los operadores.
Como resultado, los calendarios o las demás apps que almacenan o transfieren el ID de zona horaria del invierno a la primavera podrían mostrar y usar la hora local incorrecta hasta que las apps pertinentes 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 prueba con una celda de telefonía simulada o de prueba para verificar el comportamiento de la detección de zona horaria de telefonía. La celda de prueba se puede usar para simular redes con diferentes MCC y enviar señales de 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 de la TZDB de IANA (reglas de zona horaria) del dispositivo. Los indicadores de NITZ que no son coherentes con el MCC hacen que el algoritmo de telefonía se vuelva incierto.
Por ejemplo, si el MCC que usa la celda de prueba es para EE.UU., el indicador de NITZ debe contener información de UTC, desplazamiento y horario de verano que sea correcta para algún lugar de EE.UU.
Interactúa con el servicio com.android.phone
Para verificar que el dispositivo recibe sugerencias correctas de zona horaria telefónica, usa el siguiente comando:
adb shell dumpsys activity service \
com.android.phone/com.android.phone.TelephonyDebugService
Esto vuelca información de telefonía, que también se puede encontrar en los informes de errores de Android. En los dispositivos con varias SIMs, se muestra información para cada radio de SIM.
En los registros de zona horaria, se muestran las sugerencias que el proceso de telefonía envió a time_zone_detector y los motivos por los que se enviaron las sugerencias.
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")]}