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

На устройствах под управлением Android 11 или более ранней версии автоматическое определение часового пояса в 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 должен содержать информацию о «универсальном времени», смещении и переходе на летнее время, которая соответствует какой-либо точке США.

Взаимодействие с сервисом com.android.phone

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

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

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

Журналы часовых поясов показывают предложения, которые процесс телефонии отправил в time_zone_detector, и причины отправки предложений.

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