-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Valid US phone number being reported as invalid #247
Comments
Note: This is a relatively new area code: https://www.fox4news.com/news/new-area-code-945-approved-for-dallas-area |
To add to this..
604 is NOT a new area code. I ran across this trying to figure out why this wasn't parsing or formatting correctly. Instead, the parsing thinks this is a +60 country code breaking the () which doesn't make a lot of sense. |
This has now been open for a while - any movement on these simple additions? |
This also seem so be an issue when Faker is used and numbers begin with 555 |
Any workaround regarding this issue? I am having the same issue with "787" area code. |
@yogesh-stripe @jg-stripe @tanelsuurhans @usama520 This number is also parsed as invalid in original libphonenumber. You can check it here and open an issue for them. Gem's data is based on it. Phonelib.add_additional_regex :us, Phonelib::Core::FIXED_LINE, '945\d{7}' I am just not sure regarding numbering plan rules in these areas, but you can make regex to be more strict. @wflanagan You are not using default_country method correctly. It should be used like: Phonelib.default_country = :us |
Not sure if this helps but I think irb(main):010:0> Phonelib.parse('+19450000000', 'US').valid_for_country?('US')
=> false
irb(main):012:0> Phonelib.parse('+19452000000', 'US').valid_for_country?('US')
=> true The first digit of the local part can only be 2-9 (from when you could dial locally without the area code... 1 would be long distance and 0 would be the operator) |
I am using phonelib 0.6.46 and I am having trouble validating some US phone numbers with area code 945. Wondering if this is a known bug.
Here is an example failure:
irb(main):002:0> Phonelib.parse('+19450000000', 'US').valid_for_country?('US')
=> false
The text was updated successfully, but these errors were encountered: