Infeasible
Status Update
No update yet.
Comments
kk...@google.com
kk...@google.com
Hi,
Thank you for taking the time to improve libphonenumber!
We are looking into this and will respond as soon as possible.
pe...@google.com
pe...@google.com
Hi,
Thanks much for raising this issue. This is one of our known issue, which is not documented. Having phone numbers of this long are very rare. libphonenumber cannot do anything better here.
Reasons:
- JavaScript
Numbertype has limitation of 2^53 (9007199254740992) as the max literal it can hold. When provided more than that like "90018408059449376"(17 digit), JS starts rounding the value. Unfortunately this is within the range ofpossible phone number length - Both the alternatives leads to backward-incompatible changes as the type of the field '''national_number''' has to be changed; thus leading to client-side compile issue . Eg: setNationalNumber(1234) / conversions to payloads like JSON.
- Marking the field as
[jstype = JS_STRING] - Or using new JS data type
BigInt.
We will update FAQ at GitHub stating some of these points. Maybe you can compare with Number.MAX_VALUE and avoid such cases. Or post request to a Java/CPP/PY libphonenumber clients, as these langs have much more matured data type systems.
ra...@gmail.com
+923146233552
Description
Country: Japan
Example number(s) and/or ranges: 90018408059449376
Authoritative evidence (e.g.national numbering plan, operator announcement):
in Java demo it parsed as expected which is 90018408059449376 and country code +81 but in javascript it increment last digit and turn to 90018408059449380 in parse
Link from demo (
even I change country to US it still increments last number so whenever I have 17 digits number parsing doesn't work as expected in javascript
but java demo works as expected is is known bug in javascript?