`area` guessing based on `phonenumbers.geocoder.description_for_number` is wrong for some numbers

[drewler]

When a single area is extracted from the output of description_for_number, that's interpreted as if it were a state.

tz-trout/tztrout/__init__.py

Lines 90 to 92 in 9f2d1f7

	elif len(area) == 1 and area[0]:
	state = area[0].lower().strip()
	state = td.normalized_states['US'].get(state, None)

Here's an example where a phone from Philadelphia, PA thinks state is philadelphia instead of pennsylvania and fails to find it in normalized_states. Because of this, all the US timezone IDs will be returned for this number.

This behaviour is still present in phonenumbers latest version (8.13.1)

Example:

import phonenumbers
from phonenumbers.geocoder import description_for_number
from tztrout import tz_ids_for_phone

phone_number = "+14455000001"

tz_ids = tz_ids_for_phone(phone_number, "US")
print(tz_ids) # contains all of the US timezones

phone = phonenumbers.parse(phone_number, "US")
area = description_for_number(phone, "en").split(',')
print(area) # ["Philadelphia"]

[neob91-close]

This behaviour is still present in phonenumbers latest version (8.13.1)

Not sure if this is what you meant, but I do not believe this to be an issue with phonenumbers, but with the way tz-trout is using it. I looked over the docstring of description_for_number and it does not seem to guarantee that the return value for US numbers will be the state.

[drewler]

Right. The issue can't be blamed onto phonenumbers because as you say, description_for_number does not guarantee that the return value for US numbers will be the state.

What I meant is:

• Guessing area based on phonenumbers.geocoder.description_for_number produces problematic results for some numbers
• phonenumbers keeps handling some numbers in this problematic (for us at least) way, even in its latest version

I think some ways of dealing with it could be:

• Looking for an alternative way to guess the area
• Being able to identify which numbers won't return a useful area and raise some kind of error, so we know downstream these numbers won't behave properly
• Adding some additional logic on top (eg: if we know what we might not get just states but maybe "metropolitan areas" or whatever, do an extra guess).