Skip to content
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

Determination of PhoneNumber.type is incorrect #34

Closed
fikus opened this issue Mar 16, 2016 · 1 comment · Fixed by #40
Closed

Determination of PhoneNumber.type is incorrect #34

fikus opened this issue Mar 16, 2016 · 1 comment · Fixed by #40

Comments

@fikus
Copy link
Contributor

fikus commented Mar 16, 2016

The method for determining a number's type is incorrect for numbers from a region not the "main country" of a country code. For example:

    func testAntiguaPagerNumber() {
        guard let number = try? PhoneNumber(rawNumber: "12684061234") else {
            XCTFail()
            return
        }
        XCTAssertEqual(number.type, PhoneNumberType.Pager)
    }

fails because the type determination uses US metadata instead of AG metadata.

@fikus fikus changed the title PhoneNumber.type is incorrect for numbers that are not from main country Determination of PhoneNumber.type is incorrect Mar 17, 2016
@fikus
Copy link
Contributor Author

fikus commented Mar 17, 2016

In addition to using the incorrect metadata described above, the type determination can also be incorrect based on the usage of possibleNumberPattern. (This is related to the workaround in #33)

Example:

    func testUSTollFreeNumberType() {
        guard let number = try? PhoneNumber(rawNumber: "8002345678") else {
            XCTFail()
            return
        }
        XCTAssertEqual(number.type, PhoneNumberType.TollFree)
    }

The type is incorrectly determined to be PremiumRate because the premium rate possible number pattern is the generic pattern \d{10}.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant