Apply NANP leading-digit rule to suppress Unix timestamp phone false positives

[seancraven]

Hi,

I've opened this separately as I'm really not so much a fan of this.

By introducing the NANP checks on US/CA numbers we can eliminate a fair amount of what I assume will be a common false positive. However, the long-term solution is probably to set up some automation to include the Google libphonenumber rules table, and do the validation in a similar way.

I'm happy to implement this, but it needs a bit more time.

Objective

Stop 10-digit Unix timestamps (e.g. "start": 1800005580) being detected as PHONE. The phone detector only checked digit counts, so any 10-digit number with non-alphanumeric boundaries was reported as a North American phone number. A synthetic trajectory JSON file produced 153 such false positives.

Changes

• is_valid_phone now requires numbers written without + to follow the North American Numbering Plan: the 1st and 4th digits (the first digits of the area code and exchange code) must be between 2 and 9. The leading 1 of 11-digit numbers is dropped before the check.
• + numbers are unchanged (7–15 digits). Development fixtures label 8-digit numbers such as +1-555-1002 as PHONE, so applying the rule there would break them.
• Positive test detects_phone_numbers_following_nanp_rule and negative test rejects_phone_candidates_breaking_nanp_rule.

Limitations: this only deconflicts timestamps while they start with 1, which holds until 2033-05-18. Other 10-digit values whose 1st and 4th digits are 2–9 still match. All 128 existing non-+ phone fixtures already follow the rule.

Verification

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-features
• New or changed detection behavior includes positive and negative tests
• I reviewed the diff for unrelated refactoring or duplicated binding logic

[sidmohan0]

Hey @seancraven , sorry for the delay on this. First, thanks for putting it together. The timestamp false positives are a real issue, and this is a sensible improvement. I’m happy to move this forward. I’ll add a couple of regression cases for the intentionally unchanged + behavior and Unicode offsets and unblock CI.

the libphonenumber idea makes sense I think as a followup. I went ahead and created a new issue for that. Let me know if you have any other questions. Thanks again for your contribution here.

Sid

[sidmohan0]

everything merged, targeting for release of 0.4.4.

[seancraven]

Thanks Sid Keep up the good work, happy hacking!