[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-08-27 (世界標準時間)。"],[],[],null,["For devices running Android 11 or lower, automatic time zone detection in the\nAOSP relies on signals from the telephony subsystem. Because of the dependency\non the telephony subsystem, automatic time zone detection on Android 11 or lower\nis limited to telephony devices.\n\nWhen telephony time zone detection is available, it works using the [mobile\ncountry code (MCC)](https://en.wikipedia.org/wiki/Mobile_country_code) and [Network Identity and Time Zone (NITZ)](https://en.wikipedia.org/wiki/NITZ) signals.\n\nFor example, a device in Belgium can identify the time zone based solely on the\nMCC reported by nearby cell towers. This is possible because Belgium is known to\nuse a single time zone.\n\nWhen a country uses multiple time zones, the MCC alone isn't enough to identify\nthe time zone. For these countries, the device also uses NITZ signals to\nidentify the correct time zone. This works well in many places around the world\nbut it requires that NITZ signals are both available and correct and it's\ntherefore dependent on carriers.\n\nTelephony time zone detection is a *passive* detector. It runs at all times and\nso telephony suggestions are often made even when the active\n`time_zone_detector` algorithm isn't currently telephony.\n\nLimitation of telephony time zone detection\n\nEven with correct NITZ signals available, telephony time zone detection doesn't\nalways work well in every country. This is because NITZ only contains offset and\ndaylight saving information, which aren't always enough to uniquely identify a\ntime zone.\n\nThere are many places in the world where this time zone problem might occur. For\nexample, Denver Colorado and Phoenix Arizona in the US can't be distinguished\nusing NITZ signals during winter, but can during other seasons. Any location\nwith similarly overlapping time zones may experience this kind of issue.\n\nThe following table breaks down the device behavior depending on the season for\nDenver and Phoenix as an example:\n\n| Location and season | Information from MCC or NITZ | Detected time zone and behavior |\n|-------------------------|-------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|\n| Denver, Colorado Winter | Time: 1st January 2021 12:00:00 Country: US Offset: UTC-7, no daylight saving | Two zone IDs match: - America/Denver - America/Phoenix \u003cbr /\u003e Device is **correctly** set to America/Denver. |\n| Phoenix, Arizona Winter | Time: 1st January 2021 12:00:00 Country: US Offset: UTC-7, no daylight saving | Two zone IDs match: - America/Denver - America/Phoenix \u003cbr /\u003e Device is **incorrectly** set to America/Denver. |\n| Denver, Colorado Summer | Time: 1st July 2021 12:00:00 Country: US Offset: UTC-6, daylight saving | One zone ID matches: - America/Denver \u003cbr /\u003e Device is **correctly** set to America/Denver. |\n| Phoenix, Arizona Summer | Time: 1st July 2021 12:00:00 Country: US Offset: UTC-7, no daylight saving | One zone ID matches: - America/Phoenix \u003cbr /\u003e Device is **correctly** set to America/Phoenix. |\n\nThe examples in the table show that during winter, Android devices in Denver or\nArizona must choose one of two matching time zone IDs, which might be incorrect\nfor some devices but still display an apparently correct local time. The device\nclock, calendars and other apps display the expected local time even if the time\nzone ID is incorrect because both time zone IDs calculate the same local time\nduring winter.\n\nHowever, in spring when Denver observes daylight saving time and Phoenix does\nnot, some devices might temporarily show the incorrect local time if they are\nset to the wrong time zone ID for the user's location. This is corrected as soon\nas the device receives a new NITZ signal (specifically, one that contains\n\"UTC-7, no daylight saving\" offset information), but this can take some time and\nis dependent on carriers.\n\nAs a result, calendars or other apps that store or carry over the time zone ID\nfrom winter to spring might display and use the wrong local time until the\nrelevant apps update the time zone ID.\n\nDebugging and testing\n\nThe following section describes shell commands for debugging and testing the\ntelephony time zone detection feature.\n| **Note:** The command line arguments for services and their output format is unstable and can change between Android releases. Use the `help` flag to see a list of command options.\n\nTest environment setup\n\nTesters typically use a test environment with a test or simulated telephony cell\nto check telephony time zone detection behavior. The test cell can be used to\nsimulate networks with different MCCs and to send NITZ signals to devices and\nthen monitor their effects.\n\nFor the device to detect the time zone, the NITZ signal information must be\ncorrect, consistent with the MCC, and match the device's copy of the IANA TZDB\n(time zone rules). NITZ signals that are inconsistent with the MCC cause the\ntelephony algorithm to become uncertain.\n\nFor example, if the MCC used by the test cell is for the USA, the NITZ signal\nmust contain a UTC, offset, and daylight saving information that is correct for\nsomewhere in the USA.\n| **Note:** Some testers run their tests against a test cell that uses MCC 001. When Android detects MCC 001, it determines that it's in a test environment and attempts time zone detection in this state; it picks an arbitrary time zone that matches the information from the NITZ signal, independent of the time zone's country. This isn't a realistic test environment and the time zone chosen by the device might not be the one they are trying to simulate. Realistic testing requires a real MCC.\n\nInteract with the com.android.phone service\n\nTo verify that the device is receiving correct telephony time zone suggestions,\nuse: \n\n adb shell dumpsys activity service \\\n com.android.phone/com.android.phone.TelephonyDebugService\n\nThis dumps telephony information, which can also be found in Android bug\nreports. On devices with multiple SIMs, there's information for each SIM radio.\n\nThe *Time zone Logs* show the suggestions that the telephony process has sent to\nthe time_zone_detector and the reasons for sending the suggestions. \n\n```actionscript-3\nTimeServiceHelperImpl:\n SystemClock.elapsedRealtime()=11864061\n System.currentTimeMillis()=1620652067178\n Time Logs:\n...\n\nTime zone Logs:\n 18602 / 2021-05-10T09:50:21.718Z - Suggesting time zone update:\n TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='null', mMatchType=0, mQuality=0,\n mDebugInfo=[getTimeZoneSuggestion: nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,\n mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,\n mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},\n countryIsoCode=null, Detection\n reason=handleNitzReceived(TimestampedValue{mReferenceTimeMillis=14098,\n mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,\n mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}})]}\n 18831 / 2021-05-10T09:50:21.948Z - Suggesting time zone update:\n TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='Europe/London', mMatchType=3, mQuality=1,\n mDebugInfo=[findTimeZoneFromCountryAndNitz: countryIsoCode=gb,\n nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,\n mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,\n mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},\n findTimeZoneFromCountryAndNitz: lookupResult=OffsetResult{mTimeZone(ID)=Europe/London,\n mIsOnlyMatch=true}, Detection reason=handleCountryDetected(\"gb\")]}\n```"]]
