Определение часового пояса телефонии

Для устройств под управлением Android 11 или более ранних версий автоматическое определение часового пояса в Android Open Source Project (AOSP) основано на сигналах от телефонной подсистемы. Из-за зависимости от телефонной подсистемы автоматическое определение часового пояса на Android 11 или более ранних версиях ограничено телефонными устройствами.

Если функция определения часового пояса в телефонии доступна, она работает с использованием кода страны мобильной связи (MCC) и сигналов идентификации сети и часового пояса (NITZ) .

Например, устройство в Бельгии может определить часовой пояс, основываясь исключительно на данных MCC, поступающих от близлежащих вышек сотовой связи. Это возможно, поскольку известно, что в Бельгии используется единый часовой пояс.

Когда в стране используется несколько часовых поясов, одного MCC недостаточно для определения часового пояса. Для таких стран устройство также использует сигналы NITZ для определения правильного часового пояса. Это хорошо работает во многих местах по всему миру, но требует наличия и корректности сигналов NITZ, поэтому зависит от операторов связи.

Обнаружение часового пояса в телефонии — это пассивный механизм. Он работает постоянно, поэтому предложения по телефону часто выдаются даже тогда, когда активный алгоритм time_zone_detector не использует телефонию.

Ограничения определения часового пояса в телефонии.

Даже при наличии корректных сигналов NITZ определение часового пояса в телефонии не всегда работает корректно во всех странах. Это связано с тем, что NITZ содержит только информацию о смещении и переходе на летнее время, которой не всегда достаточно для однозначной идентификации часового пояса.

В мире существует множество мест, где может возникнуть подобная проблема с часовыми поясами. Например, в США, в частности в Денвере (Колорадо) и Финиксе (Аризона), сигналы NITZ нельзя различить зимой, но можно в другие времена года. Любое место с аналогичным перекрытием часовых поясов может столкнуться с подобной проблемой.

В следующей таблице показано поведение устройств в зависимости от времени года, например, в Денвере и Финиксе:

Местоположение и сезон Информация от MCC или NITZ Выявлен часовой пояс и поведение.
Денвер, Колорадо
Зима
Время: 1 января 2021 г., 12:00:00
Страна: США
Смещение: UTC-7, без перехода на летнее время.
Совпадают два идентификатора зоны:
  • Америка/Денвер
  • Америка/Финикс

Устройство корректно настроено на регион Америка/Денвер.
Финикс, Аризона
Зима
Время: 1 января 2021 г., 12:00:00
Страна: США
Смещение: UTC-7, без перехода на летнее время.
Совпадают два идентификатора зоны:
  • Америка/Денвер
  • Америка/Финикс

Устройство ошибочно настроено на Америку/Денвер.
Денвер, Колорадо
Лето
Время: 1 июля 2021 г., 12:00:00
Страна: США
Смещение: UTC-6, летнее время
Совпадает один идентификатор зоны:
  • Америка/Денвер

Устройство корректно настроено на регион Америка/Денвер.
Финикс, Аризона
Лето
Время: 1 июля 2021 г., 12:00:00
Страна: США
Смещение: UTC-7, без перехода на летнее время.
Совпадает один идентификатор зоны:
  • Америка/Финикс

Устройство корректно настроено на Америку/Финикс.

Примеры в таблице показывают, что зимой устройства Android в Денвере или Аризоне должны выбирать один из двух совпадающих идентификаторов часового пояса, который может быть неверным для некоторых устройств, но при этом отображать, казалось бы, правильное местное время. Часы, календари и другие приложения устройства отображают ожидаемое местное время, даже если идентификатор часового пояса неверен, поскольку оба идентификатора часового пояса рассчитывают одно и то же местное время зимой.

Однако весной, когда в Денвере действует летнее время, а в Финиксе — нет, некоторые устройства могут временно отображать неверное местное время, если для них установлен неправильный идентификатор часового пояса для местоположения пользователя. Это исправляется, как только устройство получает новый сигнал NITZ (в частности, сигнал, содержащий информацию о смещении "UTC-7, без летнего времени"), но это может занять некоторое время и зависит от операторов связи.

В результате календари или другие приложения, которые хранят или переносят идентификатор часового пояса с зимы на весну, могут отображать и использовать неправильное местное время до тех пор, пока соответствующие приложения не обновят идентификатор часового пояса.

Отладка и тестирование

В следующем разделе описаны команды оболочки для отладки и тестирования функции определения часового пояса в телефонии.

Настройка тестовой среды

Как правило, тестировщики используют тестовую среду с тестовой или имитированной телефонной ячейкой для проверки поведения определения часового пояса в телефонии. Тестовая ячейка может использоваться для имитации сетей с различными MCC и для отправки сигналов NITZ на устройства с последующим мониторингом их воздействия.

Для того чтобы устройство могло определить часовой пояс, информация в сигнале NITZ должна быть корректной, соответствовать MCC и совпадать с копией базы данных IANA TZDB (правила часовых поясов), хранящейся в устройстве. Сигналы NITZ, не соответствующие MCC, приводят к неопределенности в работе телефонного алгоритма.

Например, если используемый тестовой ячейкой MCC предназначен для США, сигнал NITZ должен содержать информацию о времени UTC, смещении и переходе на летнее время, которая является корректной для какой-либо точки на территории США.

Взаимодействуйте со службой com.android.phone

Чтобы убедиться, что устройство получает правильные рекомендации по часовым поясам для телефонных звонков, используйте:

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

Это позволяет получить доступ к телефонной информации, которую также можно найти в отчетах об ошибках Android. На устройствах с несколькими SIM-картами информация доступна для каждого SIM-модуля.

В журналах часовых поясов отображаются предложения, отправленные процессом телефонии в детектор часовых поясов, а также причины отправки этих предложений.

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