針對搭載 Android 11 以下版本的裝置，系統會在以下位置自動偵測時區： Android 開放原始碼計畫仰賴電話子系統的信號。由於依附元件 (在電話子系統上；在 Android 11 以下版本中自動偵測時區) 僅限於電話裝置。
在可偵測電話時區時，這項服務會使用 行動裝置國家/地區代碼 (MCC) 和 網路身分和時區 (NITZ) 信號
舉例來說，法國的裝置只會根據 鄰近行動通信基地台的 MCC。這可能是因為法國當地人知道 使用單一時區。
若國家/地區使用多個時區，光是「我的客戶中心」還不夠明確 時區。在這些國家/地區，裝置也會使用 NITZ 信號來 找出正確的時區這項功能在全球許多地方都能正常運作 但需要 NITZ 訊號且能夠取得正確資訊 也取決於電信業者
電話時區偵測屬於被動偵測工具。隨時都在運作
因此，即使啟用電話通訊功能
time_zone_detector 演算法目前並非電話通訊。
電話時區偵測限制
即使有正確的 NITZ 訊號，電話時區偵測功能仍無法偵測 總是在各種國家/地區都無往不利這是因為 NITZ 只包含偏移量， 日光節約資訊，但某些資訊可能無法 時區。
世界上許多地方都可能發生這個時區問題。 舉例來說，美國的科羅拉多州和鳳凰城和鳳凰城等區域無法設為 於冬季期間使用 NITZ 信號進行區分，但在其他季節時仍可。 任何時區重疊的地點都可能發生這類情況 問題。
下表根據季節細分的裝置行為 代表 Denver 和 Phoenix
| 地區和季別 | 我的客戶中心或 NITZ 提供的資訊 | 偵測到的時區和行為 |
|---|---|---|
| 丹佛、科羅拉多州 冬天 |
時間：2021 年 1 月 1 日 12:00:00 國家/地區：美國 偏移：UTC-7，無日光節約時間 |
兩個區域 ID 相符：
裝置已正確設為美國/丹佛。 |
| 鳳凰城、亞利桑那州 冬天 |
時間：2021 年 1 月 1 日 12:00:00 國家/地區：美國 偏移：UTC-7，無日光節約時間 |
兩個區域 ID 相符：
裝置未正確設為美國/丹佛。 |
| 丹佛、科羅拉多州 夏季 |
時間：2021 年 7 月 1 日 12:00:00 國家/地區：美國 偏移：UTC-6，日光節約時間 |
與 1 個區域 ID 相符：
裝置已正確設為美國/丹佛。 |
| 鳳凰城、亞利桑那州 夏季 |
時間：2021 年 7 月 1 日 12:00:00 國家/地區：美國 偏移：UTC-7，無日光節約時間 |
與 1 個區域 ID 相符：
裝置已正確設為 America/Phoenix。 |
以上範例顯示冬季期間的 Android 裝置、丹佛市 亞利桑那州必須在兩個相符時區 ID 中擇一使用，但這可能不正確 但部分裝置仍可顯示正確的當地時間。裝置 時鐘、日曆和其他應用程式會顯示預期的當地時間，即使 時區 ID 計算的當地時區相同，因此不正確。 就能快速上手
但在春天時，丹佛觀察到日光節約時間 而鳳凰城也確實做到 不會，如果設定裝置，部分裝置可能會暫時顯示不正確的當地時間 使用者位置的時區 ID 錯誤系統會盡快修正這個問題 因裝置收到新的 NITZ 信號 (具體來說 「UTC-7，無日光節約時間」偏移資訊) 但實際作業可能需要一段時間，實際情形取決於電信業者。
因此，儲存或轉移時區 ID 的日曆或其他應用程式 的當地時間可能在冬天到春季顯示，而且在正確的時區前， 相關應用程式會更新時區 ID。
偵錯和測試
下節說明用於偵錯及測試 電話時區偵測功能
測試環境設定
測試人員通常會使用測試環境，內含測試或模擬電話手機 檢查電話時區偵測行為。測試儲存格可用來 以不同的 MCC 模擬網路，並將 NITZ 信號傳送到裝置，以及 然後監控它們的效果
如要讓裝置偵測時區，NITZ 信號資訊必須 正確、與 MCC 一致，且符合裝置版本的 IANA TZDB (時區規則)。與 MCC 不一致的 NITZ 信號會導致 才能變得不確定
舉例來說，如果測試儲存格使用的 MCC 代表美國，NITZ 就會傳回 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")]}