Wykrywanie strefy czasowej w telefonii

W przypadku urządzeń z Androidem 11 lub starszym automatyczne wykrywanie strefy czasowej w AOSP opiera się na sygnałach z podsystemu telefonicznego. Ze względu na zależność od podsystemu telefonicznego automatyczne wykrywanie strefy czasowej na urządzeniach z Androidem 11 lub starszym jest ograniczone do urządzeń telefonicznych.

Gdy wykrywanie strefy czasowej za pomocą telefonii jest dostępne, działa ono na podstawie kodu kraju sieci komórkowej (MCC) i sygnałów Network Identity and Time Zone (NITZ).

Na przykład urządzenie w Belgii może określić strefę czasową wyłącznie na podstawie kodu MCC zgłoszonego przez pobliskie stacje bazowe. Jest to możliwe, ponieważ w Belgii obowiązuje jedna strefa czasowa.

Gdy w danym kraju obowiązuje kilka stref czasowych, sam kod MCC nie wystarczy do określenia strefy czasowej. W tych krajach urządzenie używa też sygnałów NITZ do identyfikowania prawidłowej strefy czasowej. To rozwiązanie sprawdza się w wielu miejscach na świecie, ale wymaga dostępności i poprawności sygnałów NITZ, a zatem zależy od operatorów.

Wykrywanie strefy czasowej na podstawie telefonii to pasywny detektor. Działa on przez cały czas, więc sugestie dotyczące telefonii są często wyświetlane nawet wtedy, gdy aktywny algorytm time_zone_detector nie jest obecnie związany z telefonią.

Ograniczenie wykrywania strefy czasowej za pomocą telefonii

Nawet jeśli dostępne są prawidłowe sygnały NITZ, wykrywanie strefy czasowej przez telefonię nie zawsze działa dobrze w każdym kraju. Dzieje się tak, ponieważ NITZ zawiera tylko informacje o przesunięciu i czasie letnim, które nie zawsze wystarczają do jednoznacznego określenia strefy czasowej.

Wiele miejsc na świecie może mieć ten problem ze strefą czasową. Na przykład w Stanach Zjednoczonych w okresie zimowym nie można odróżnić Denver w Kolorado od Phoenix w Arizonie za pomocą sygnałów NITZ, ale w innych porach roku jest to możliwe. Ten problem może wystąpić w każdej lokalizacji, w której strefy czasowe podobnie się pokrywają.

W tabeli poniżej znajdziesz informacje o tym, jak zachowuje się urządzenie w zależności od pory roku w Denver i Phoenix:

Przykłady w tabeli pokazują, że zimą urządzenia z Androidem w Denver lub Arizonie muszą wybrać jeden z 2 pasujących identyfikatorów stref czasowych, który może być nieprawidłowy w przypadku niektórych urządzeń, ale nadal wyświetlać pozornie prawidłowy czas lokalny. Zegar urządzenia, kalendarze i inne aplikacje wyświetlają oczekiwany czas lokalny, nawet jeśli identyfikator strefy czasowej jest nieprawidłowy, ponieważ oba identyfikatory stref czasowych obliczają ten sam czas lokalny w okresie zimowym.

Jednak wiosną, gdy w Denver obowiązuje czas letni, a w Phoenix nie, niektóre urządzenia mogą tymczasowo wyświetlać nieprawidłowy czas lokalny, jeśli są ustawione na nieprawidłowy identyfikator strefy czasowej dla lokalizacji użytkownika. Zostanie to skorygowane, gdy tylko urządzenie otrzyma nowy sygnał NITZ (zwłaszcza taki, który zawiera informacje o przesunięciu „UTC-7, bez czasu letniego”), ale może to zająć trochę czasu i zależy od operatorów.

W rezultacie kalendarze i inne aplikacje, które przechowują lub przenoszą identyfikator strefy czasowej z zimy na wiosnę, mogą wyświetlać i używać nieprawidłowego czasu lokalnego, dopóki nie zaktualizują identyfikatora strefy czasowej.

Debugowanie i testowanie

W sekcji poniżej znajdziesz polecenia powłoki do debugowania i testowania funkcji wykrywania strefy czasowej na podstawie telefonii.

Konfigurowanie środowiska testowego

Testerzy zwykle używają środowiska testowego z testową lub symulowaną komórką telefoniczną, aby sprawdzić działanie wykrywania strefy czasowej w przypadku telefonii. Komórka testowa może służyć do symulowania sieci z różnymi kodami MCC i wysyłania sygnałów NITZ do urządzeń, a następnie do monitorowania ich wpływu.

Aby urządzenie mogło wykryć strefę czasową, informacje o sygnałach NITZ muszą być prawidłowe, zgodne z kodem MCC i odpowiadać kopii bazy danych IANA TZDB (zasad stref czasowych) na urządzeniu. Sygnały NITZ, które są niezgodne z kodem MCC, powodują, że algorytm telefoniczny staje się niepewny.

Jeśli np. kod MCC używany przez komórkę testową jest przeznaczony dla Stanów Zjednoczonych, sygnał NITZ musi zawierać informacje o czasie UTC, przesunięciu i czasie letnim, które są prawidłowe dla Stanów Zjednoczonych.

korzystać z usługi com.android.phone,

Aby sprawdzić, czy urządzenie otrzymuje prawidłowe sugestie strefy czasowej telefonii, użyj:

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

W ten sposób uzyskasz informacje o telefonii, które można też znaleźć w raportach o błędach Androida. Na urządzeniach z kilkoma kartami SIM wyświetlane są informacje o każdym radiu SIM.

Dzienniki strefy czasowej pokazują sugestie, które proces telefoniczny wysłał do usługi time_zone_detector, oraz powody wysłania tych sugestii.

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