BlogData

A phone number has a timezone. Its owner can travel.

The timezone on a phone lookup comes from its numbering-plan prefix. It provides context about the number, not the handset's current location.

A New York phone number doesn't change when its owner visits California. The area code still tells you something about the number, but it can't tell you where the person is standing.

That's the distinction behind deep.timezone on /phone. It comes from the number's prefix in the numbering plan. For +12127365000, the value is America/New_York. It's an IANA timezone id, so you can use it with the same date libraries and timezone lookups you already use elsewhere.

The lookup checks the longest matching prefix. Some prefixes identify one timezone. Others cover several. When the match contains more than one zone, the response leaves deep.timezone null. The toll-free example +18005882300 returns null for that reason. Choosing the first zone in the list would make the answer look more specific than it is.

This can be useful context for a contact record or a first guess in a form. If your application needs someone's actual timezone, let them provide or confirm it. A number can move with its owner, and the prefix doesn't update to follow their travels.

Request /phone/{number}?deep=true to include the field alongside the parsed number and its formats. This detail is included on every plan and does not require another lookup. It answers what can be learned from the number itself, with no claim that a phone was located or contacted.