# An area code is not a time zone

NANPA lists 24 area codes on more than one clock, and a lookup reads the exchange. Which numbers answer two zones, and what in_call_window checks.

Date: 2026-09-27

An area code does not settle a time zone: NANPA's area-code report of 27 September 2026 lists 24 North American area codes in service on more than one clock, and Spaw's phone lookup takes a number's zone from the numbering metadata, which reads the exchange (the three digits after the area code) where it has an entry for it and falls back to the area code's default where it has none. Some numbers in seven area codes answer two zones, because the metadata gives their exchange, or their whole code, a two-zone entry. This guide sets NANPA's list beside what a Spaw lookup answers for every assigned exchange, then explains what `local_time`, `utc_offsets` and `in_call_window` do with the result, and what they cannot know.

## Two sources, two levels of detail

NANPA, the North American Numbering Plan Administrator, publishes a report with one row per area code (https://reports.nanpa.com/public/npa_report.csv, file dated 27 September 2026). Its `TIME_ZONE` column gives most codes one or more letters: E for Eastern, C for Central, M for Mountain, P for Pacific, A for Atlantic, N for Newfoundland and AK for Alaska. Hawaii and the Pacific territories are given as UTC offsets, such as "(UTC-10)" for 808, and 775 carries a note instead. A code marked "EC" covers ground on both clocks. The column describes the area code as a whole; it does not say which exchanges keep which clock. Spaw syncs that report and NANPA's central office code report daily, and the Canadian Numbering Administrator's table weekly; what each copy holds is on [the phone data sources page](/tools/phone-number-lookup/sources).

A lookup does not read that column. The `timezones` field comes from libphonenumber, the numbering metadata behind Android (Apache-2.0; the release in use is on the [status page](/status), under phone numbering metadata), whose time-zone map for +1 is keyed on at most the area code and the exchange, the six digits called the [NPA/NXX](/glossary/npa-nxx). When the map has an entry for the exchange, the number gets that entry. When it has none, the number takes the nearest shorter entry, usually the area code's own default, which is one zone for most codes and two for a few. Spaw then drops any zone the tz database places in another country, so a Newfoundland number is not given Puerto Rico's clock. Nothing is finer than the exchange: in a pooled code a thousands-block can change the holder, never the zone.

## The 24 codes NANPA lists on more than one clock

The right-hand column counts the central office codes that NANPA's code report of 26 September 2026 lists as assigned in each area code (for the Canadian codes, the Canadian table of 23 September 2026), each looked up as a number through the same zone code the API runs. Zones are tz database names without the "America/" prefix, and "+" marks an exchange whose numbers answer both zones.

| Code | Area | NANPA lists | A lookup answers, by assigned exchange |
| --- | --- | --- | --- |
| 208 | Idaho | MP | Boise + Los_Angeles 443, Denver 271, Los_Angeles 71 |
| 219 | Indiana | EC | New_York 378, Chicago 117 |
| 270 | Kentucky | EC | New_York 637, Chicago 132 |
| 308 | Nebraska | CM | Chicago 431, Denver 32 |
| 364 | Kentucky | EC | New_York 72 |
| 423 | Tennessee | EC | Chicago 542, New_York 221 |
| 448 | Florida | EC | New_York 118 |
| 458 | Oregon | MP | Los_Angeles 224 |
| 541 | Oregon | MP | Los_Angeles 777, Denver 4 |
| 574 | Indiana | EC | New_York 401, Chicago 2 |
| 605 | South Dakota | CM | Denver + North_Dakota/Center 551, Chicago 142, Denver 52 |
| 606 | Kentucky | EC | New_York 638, Chicago 1 |
| 620 | Kansas | CM | Chicago 703, Denver 2 |
| 701 | North Dakota | CM | Denver + North_Dakota/Center 582, Chicago 148, Denver 13 |
| 729 | Tennessee | EC | Not accepted by the metadata yet; no assigned exchange |
| 775 | Nevada | "PT/MT only for W Wendover" | Boise + Los_Angeles 443, Los_Angeles 156, Denver 1 |
| 785 | Kansas | CM | Chicago 724, Denver 3 |
| 807 | Ontario | EC | Toronto 288, Winnipeg 9 |
| 812 | Indiana | EC | New_York 735, Chicago 50 |
| 850 | Florida | EC | New_York 559, Chicago 226 |
| 867 | Yukon, Northwest Territories, Nunavut | CMP | Fort_Nelson 241, Edmonton 9, Vancouver 8, Winnipeg 1, Toronto 1 |
| 906 | Michigan | EC | New_York 348, Chicago 12 |
| 915 | Texas | CM | Denver 367 |
| 931 | Tennessee | EC | Chicago 538 |

The table reads four ways.

- **Two zones for one number: 208, 605, 701 and 775.** Most of their assigned exchanges answer a two-zone entry rather than one zone: Boise and Los_Angeles (Mountain and Pacific) in 208 and 775, Denver and North_Dakota/Center (Mountain and Central) in 605 and 701.
- **One zone per number, different zones across the code: 14 codes**, 219, 270, 308, 423, 541, 574, 606, 620, 785, 807, 812, 850, 867 and 906. Every number answers one zone, so `local_time` is given, but the code's exchanges do not all answer the same one.
- **One zone for the whole code: 364, 448, 458, 915 and 931.** Every assigned exchange answers the same zone although NANPA lists two, so a number on the other clock is answered an hour out. 364 and 448 are overlays of 270 and 850, which do split; 458 overlays 541.
- **Not in the metadata yet: 729.** NANPA lists the Tennessee overlay in service from 5 September 2025, but libphonenumber does not accept it yet (neither 9.0.37 nor 9.0.40, the release the live service ran on 27 September 2026, does), so a 729 number answers `invalid_number` with no zone. NANPA's code report lists no assigned exchange in it yet.

Where the answer comes from matters more than NANPA's letters. In 219, 378 of the 495 assigned exchanges have no entry of their own and take the code's default, New_York; in 423, 542 of 763 take its default, Chicago; in 915 and 931 every exchange does. An exchange the metadata never listed, or one assigned since, answers the default whichever clock its rate centre keeps.

## Codes NANPA lists on one clock that a lookup splits

| Code | Area | NANPA lists | A lookup answers, by assigned exchange |
| --- | --- | --- | --- |
| 986 | Idaho | P | Boise + Los_Angeles 187, every one |
| 907 | Alaska | AK | Adak + Anchorage 507, Juneau 149, Pacific/Honolulu 1 |
| 928 | Arizona | M | Phoenix 617, Denver + Phoenix 16 |
| 250 | British Columbia | P | Vancouver 759, Edmonton 22 |
| 418 | Quebec | E | Toronto 775, Halifax 2 |
| 709 | Newfoundland and Labrador | N | St_Johns 628, Halifax 3 |

986 overlays 208 across the whole of Idaho, yet NANPA gives it P and 208 MP; the metadata gives every 986 number both of 208's clocks. 930, the overlay of 812, is the opposite case: NANPA lists it E beside 812's EC, and all 158 of its assigned exchanges answer New_York. Adak, in 907, keeps Hawaii-Aleutian time, an hour behind Anchorage. The 16 exchanges of 928 that answer Denver and Phoenix are on one clock from early November to mid-March, while Denver is on standard time, which Arizona keeps all year, and an hour apart the rest of the year.

Across both tables, 2,729 assigned exchanges answer two zones for every number in them: 443 in 208, 187 in 986, 551 in 605, 582 in 701, 443 in 775, 507 in 907 and 16 in 928. That is 1.4% of the 197,177 central office codes NANPA lists as assigned in the United States. Each area-code page in the lookup tool shows both views, a "Time zones" row with the zones its assigned exchanges answer and a "Time zones (NANPA)" row with the report's zones; the phone facts pages for [the United States](/tools/phone-number-lookup/countries/us) and [Canada](/tools/phone-number-lookup/countries/ca) cover the rest of each country's plan.

## What the clock fields do with the zones

Every single and batch answer carries three clock fields beside `timezones`, worked out on each request and never stored:

| Field | What it holds |
| --- | --- |
| `utc_offsets` | The distinct current UTC offsets of the zones, sorted west to east. More than one means the zones disagree right now. |
| `local_time` | The local time at the number in ISO 8601, only when every zone shares one offset; otherwise null. |
| `in_call_window` | Only when the request sends `call_window`: true when the local time in every zone is inside the window, false when any is outside. Null without a window, without zones, and on an answer served from the suppression list. |

The window is "HH:MM-HH:MM" in the number's local time, from the start minute up to, not including, the end minute. It may run past midnight ("21:00-08:00"), and a window whose start equals its end is empty. `POST /api/v1/phone` and the batch endpoint take it; a bulk run takes none, and its `local_time` is the clock when the row was processed.

For +1 208 555 0100, a number in the range set aside for fiction, a lookup at 15:30 UTC on 27 September 2026 with `"call_window": "09:00-20:00"` answers:

```json
"timezones": ["America/Boise", "America/Los_Angeles"],
"local_time": null,
"utc_offsets": ["-07:00", "-06:00"],
"in_call_window": false
```

It is 09:30 in Boise and 08:30 in Los Angeles, so the window is open on one clock only. An hour later both are inside and the answer turns true. Over the day, a window eleven hours long on one clock is true for ten hours for this number, from 09:00 in Los Angeles to 20:00 in Boise. Every two-zone number in the tables above loses the same hour, except the 928 exchanges while their two zones share a clock.

## Outside North America, a mobile gets the zones listed for its calling code

In most countries a mobile number is not tied to a place, and libphonenumber gives a mobile every zone its metadata lists for the country's calling code. It ties mobiles to an area only in North America, where they share the exchanges, and in a few plans such as Mexico's, Argentina's, Brazil's and China's. The list is usually every clock the country keeps, but not always: Russia's leaves out Kaliningrad (+02:00), and Papua New Guinea's names only Port Moresby. Where the list holds several clocks, a mobile answers all of them, and a window is true only in the hours they share. When the example mobile of each of the 244 regions that have one in libphonenumber's metadata was looked up on 27 September 2026 (9.0.37 and 9.0.40 give the same answers), 15 answered more than one zone. Christmas Island and the Cocos Islands share Australia's example number and answer its six zones, and the two zones of Kazakhstan and of Palestine keep one clock that day. The other eleven, measured by running the lookup through 27 September 2026:

| Country | Zones a mobile answers | UTC offsets that day | Hours a 09:00-20:00 window is true |
| --- | --- | --- | --- |
| [Russia](/tools/phone-number-lookup/countries/ru) | 13 | 10, from +03:00 to +12:00 | 2 |
| [Australia](/tools/phone-number-lookup/countries/au) | 6 | 5, from +08:00 to +10:30 | 8.5 |
| Mongolia | 3 | 2 | 10 |
| Greenland | 3 | 2, -03:00 and -01:00 | 9 |
| Kiribati | 3 | 3, from +12:00 to +14:00 | 9 |
| French Polynesia | 3 | 3, from -10:00 to -09:00 | 10 |
| Spain | 2, Madrid and Canary | 2 | 10 |
| Portugal | 2, Lisbon and Azores | 2 | 10 |
| Ecuador | 2, Guayaquil and Galapagos | 2 | 10 |
| New Zealand | 2, Auckland and Chatham | 2, +13:00 and +13:45 | 10.25 |
| DR Congo | 2, Kinshasa and Lubumbashi | 2 | 10 |

Russia keeps 11 UTC offsets, from +02:00 to +12:00, and a Russian mobile answers the 10 from +03:00, so a true window for one says nothing about the clock in Kaliningrad, an hour behind Moscow. A Kaliningrad landline is filed under Bucharest's zone in the metadata; Spaw drops that zone as Romania's, and a number left with no zone of its own country answers every zone of that country, Kaliningrad's among them.

The metadata names eight zones for +61. Two of them belong to Christmas Island and the Cocos Islands, which the tz database files under their own country codes, so Spaw keeps the six in Australia, and they sit on five clocks all year. From 4 October 2026, when the zones that keep daylight saving time move their clocks forward, the spread widens from two and a half hours to three, and the same window is true for eight hours (computed with the clock set to 18 January 2027).

## What the answer cannot know

- **Where the person is.** The zone is where the number was issued, not where the person is. A mobile travels with its owner, a VoIP number can be answered anywhere, and nothing Spaw reads from open data says where anyone is today.
- **Whether the metadata is right for an exchange.** No field flags an exchange that took its area code's default; the tables above show how often that happens.
- **Whether a call or text may be made.** No holiday calendar and no do-not-call register is checked. A true `in_call_window` says the clocks are inside your window, nothing more.

## Two federal calling-hour rules, quoted as context

In the United States, 47 CFR 64.1200(c)(1) bars telephone solicitations to a residential subscriber "before the hour of 8 a.m. or after 9 p.m. (local time at the called party's location)", and the FTC's Telemarketing Sales Rule, 16 CFR 310.4(c), sets the same hours in "local time at the called person's location" (https://www.ecfr.gov/current/title-47/section-64.1200 and https://www.ecfr.gov/current/title-16/section-310.4, eCFR current to 24 September 2026, read 27 September 2026). Both are quoted here as context. Both measure the hour where the person is, which a phone number cannot tell you. Other rules may set different hours; check the ones that apply to you. `in_call_window` is clock arithmetic, not compliance advice, and this guide is not legal advice: you choose the window.

## Using the answer

- **Send the window in the number's local time and branch on the boolean.** True means every zone the number answers is inside it, false means at least one is not, and null means nothing was checked (no zone, or an answer served from your suppression list): treat it as not checked, never as inside.
- **For the split codes, build in the hour yourself if it matters.** A window one hour narrower at each end, 10:00-19:00 for a 09:00-20:00 window, is true only when a clock one hour either side of the answer is inside the wider window too.
- **Check at call time, not at import.** `local_time` and `in_call_window` are the clock of the request that made them. A list checked in the morning says nothing about the afternoon, so look the number up again, or recompute from `timezones`, before dialling.
- **To see the zones for a list without an API key,** paste up to 200 numbers into the [phone number formatter](/tools/phone-number-formatter). It shows each number's zone, or, for a number on several, how many and the UTC offsets they span, with the local time when they share one clock; the CSV copy names every zone.

## How the tables were computed

Every central office code that NANPA's code report of 26 September 2026 lists as assigned in the codes above, and every code the Canadian table of 23 September 2026 lists as assigned in the Canadian ones, was looked up as one number through Spaw's own zone code (libphonenumber 9.0.37 and 9.0.40, which give identical counts, narrowed to the number's country), and the answers were counted by zone. The offsets and window hours were measured by running the lookup with its clock fixed at five-minute steps through 27 September 2026 and 18 January 2027. A new metadata release can move any of these counts.

## What to do next

- Read the [phone intelligence guide](/docs/phone-intelligence) for every field of the answer.
- Check the request and response on the [POST /api/v1/phone reference](/docs/api/validate-phone) and the [batch reference](/docs/api/lookup-phone-batch).
- See why the same exchanges cannot tell a mobile from a landline in [why US numbers cannot be split into mobile and landline](/guides/why-us-numbers-cannot-be-split-into-mobile-and-landline).

Reference: https://spaw.co/guides/an-area-code-is-not-a-time-zone