> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# NANP area-code and state resolution — inventory boundaries

> Where the +1 area-code → IANA timezone inventory and the area-code → USPS state map start and stop: the resolution order, the states the lookup has no entries for, the DST-split-state mitigations, and how to override with a tenant-owned timezone hint.

# NANP area-code and state resolution — inventory boundaries

Two inventory tables underneath every quiet-hours and calling-window
verdict decide what a recipient's number can resolve to: the **NANP
timezone inventory** (IANA zone → assigned area codes) and the **US
state map** (area code → USPS state code). Both ship with Devotel Orbit
and both are rebuilt from the same NANPA Active Codes report — they
agree with each other by construction, so a recipient resolves
identically in the quiet-hours gate, the voice pre-dial guard, the
state-overlay intersection, and the recording-consent gate.

This page documents where the inventories **stop** — which numbers
resolve, which resolve to nothing, and what a blank lookup means for
your verdict. It pairs with
[recipient timezone resolution](/concepts/recipient-timezone-resolution),
which walks the same chain from the quiet-hours consumer's side; this
one is the inventory reference it cites when your question is "why did
the lookup have nothing for this number?"

## 1. The alias-resolution order

A recipient timezone alias resolves by first match wins:

1. **Explicit hint.** An IANA zone passed as `recipientTimezone` (send
   path) or `timezone_override` (preview) wins over every automatic
   source. A valid hint is authoritative.
2. **+1 NANP lookup.** For `+1` numbers, the three-digit area code
   indexes the NANP timezone inventory and returns that zone's IANA
   name.
3. **Country-prefix lookup.** For non-`+1` numbers, the E.164 country
   calling code resolves longest-prefix-first to a representative IANA
   zone (a capital-city zone for multi-zone countries).
4. **Verdict-dependent fallback.** When none of the above resolves,
   the outcome depends on the surface: the org default timezone feeds
   recipients with no usable number (email, push), and beyond that the
   recipient lands on your `unknown_timezone_policy` — fail-open
   `skip`, fail-closed `deny`, or the deterministic `enforce_utc`. The
   one exception is the TCPA federal voice dial window, which always
   fails closed for US recipients regardless of your policy; the
   platform owns that wire outright.

State resolution is a parallel projection of step 2: for a `+1` US
number, the same area code also indexes the US state map. Both
projections read the one inventory, so the timezone and the state it
returns can never disagree about which lookup ran.

## 2. State-blank alias coverage per USPS code

The US state map ships with roughly **170 single-state area-code
assignments**, built as the union of the two gates that consume it —
the mini-TCPA calling-window overlays and the recording-consent gate.
Its coverage is deliberately wider than either gate needs: a recipient
in a state with no overlay and no special consent rule still resolves
to a USPS code, which lands on the audit record for filtering.

That still leaves most USPS codes with **no** entries. The states the
lookup can return today:

| Coverage class | USPS codes |
| - | - |
| Mini-TCPA overlay states | FL, OK, MS, LA, AL, AR, WV |
| Two-party-consent states (recording gate) | CA, IL, WA, and the rest of the consent list on [recording consent](/compliance/recording-consent) |
| Included for union coverage (no gate effects) | CT, DE, HI, MA, MD, MT, NH, NY, OR, PA, TX, VT |

A `+1` number in any **other** state — say Georgia, Ohio, or Arizona —
resolves a timezone but returns **no state**. That blank is not an
error and blocks nothing: an unresolved state means "no state overlay
applies; federal window unchanged," and the recording-consent gate
treats it as one-party-consent territory. The map grows over time as
assignments are sourced from NANPA's monthly report; gates never need
to change when it does.

### DST-split-state mitigations

US DST is not state-uniform, and the inventory absorbs the three hard
cases by assigning area codes to the **IANA sub-zone that actually
covers them** rather than a generic shared zone:

* **No-DST states.** Arizona's area codes resolve to
  `America/Phoenix` (UTC-7 year-round) and Hawaii's `808` to
  `Pacific/Honolulu` (UTC-10 year-round) — never to a DST-observing
  zone, so spring and fall crossover weekends change nothing for these
  recipients.
* **IANA sub-zones.** Indiana resolves to
  `America/Indiana/Indianapolis`, Michigan to `America/Detroit`, and
  Idaho to `America/Boise` — the IANA database's own split-out zones,
  so the offset math is correct even where a state straddles a legacy
  boundary.
* **Year-round Canadian zones.** Saskatchewan's `306`, `474`, and
  `639` resolve to `America/Regina` (UTC-6 year-round, no DST) rather
  than a generic "Central" label.

A "Mountain" or "Eastern" label in your CRM is ambiguous across these
cases; the resolved IANA name is not. Where a state spans two zones
with no sub-zone entry, area codes are assigned to the zone of the
state's dominant share — the inventory keeps single-zone assignments
per area code and never returns candidates.

## 3. Worked example — blocked calls per alias category

What each lookup category does to an actual dial at \~8:30 PM Eastern
on a Tuesday (federal voice window closes at 9 PM recipient-local):

| Recipient | Lookup outcome | Verdict |
| - | - | - |
| `+13055551234` (Miami, mapped) | `America/New_York` + state `FL` | Inside window — allowed; the FL overlay (8 AM–8 PM) then applies |
| `+14805551234` (Phoenix, no-DST) | `America/Phoenix`; state blank | Allowed until 9 PM Phoenix-local; blank state changes nothing |
| `+18085551234` (Honolulu, no-DST) | `Pacific/Honolulu`; state `HI` (union coverage) | Allowed until 9 PM Honolulu-local |
| `+18005551234` (toll-free) | No timezone by design | Campaign/dialer voice: held — `TCPA_TIMEZONE_UNKNOWN`. SMS/other channels: follow your `unknown_timezone_policy`, default fail-open |
| `+19435551234` (Georgia overlay area code, mapped) | `America/New_York`; state blank | Allowed inside the federal window; no GA overlay exists |
| `+19995551234` (unassigned NPA) | No timezone — not yet in the inventory | Same posture as toll-free: held on the federal voice path, policy-controlled elsewhere; pass an explicit hint to release |
| `+442012345678` (non-NANP) | Country-prefix → `Europe/London`; state `null` by design | Outside TCPA jurisdiction; quiet-hours gates that consult a timezone use `Europe/London` |

Two readable shapes of "blocked" come out of this:

* **Wrong-zone blocking.** The Miami recipient above is blocked at
  8:30 PM by the FL overlay even though the federal window is still
  open — the resolution worked; the overlay is the gate. Debug those
  with the resolved timezone and state the
  [quiet-hours preview](/compliance/quiet-hours-preview) echoes.
* **Resolution-failure blocking.** Toll-free and unassigned-NPA
  recipients are held on the voice path because the platform refuses
  to guess a timezone under the federal guard. The release is the
  explicit hint below, not a policy flip.

## 4. Tenant-owned timezone-hint override

Number portability means an area code reflects where a number was
**assigned**, not where the subscriber lives now — a Miami `305`
mobile can belong to someone in Oregon. When your CRM knows better,
override step 2 with the tenant-owned hint:

```bash theme={null}
curl -G "https://api.orbit.devotel.io/api/v1/compliance/quiet-hours/preview" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  --data-urlencode "phone=+13055551234" \
  --data-urlencode "channel=sms" \
  --data-urlencode "timezone_override=America/Los_Angeles"
```

* **Per send:** pass `recipientTimezone` with an IANA name
  (`America/Phoenix`, not `UTC-7`). It wins over the inventory, the
  country-prefix map, and the org default.
* **Per preview:** `timezone_override` does the same for debugging —
  the response's `local_timezone` tells you which source won.

The hint is a tenant-owned control like every other resolution knob
(org default timezone, `unknown_timezone_policy`); the inventories
themselves are platform-maintained and update with the NANPA feed.
Verification workflow and policy-value selection live on
[recipient timezone resolution](/concepts/recipient-timezone-resolution).

## See also

* [Recipient timezone resolution](/concepts/recipient-timezone-resolution) —
  the consumer-side map of the same chain
* [Number timezone and state resolution](/compliance/number-timezone-resolution) —
  the unresolvable-area-code fail posture per surface
* [US calling windows](/compliance/state-calling-windows) — the state
  overlays the USPS-code leg feeds
* [Recording consent](/compliance/recording-consent) — the
  two-party-consent gate that shares the state map
* [Quiet-hours preview](/compliance/quiet-hours-preview) — echo the
  resolved timezone and state without sending