Integers glitch after reaching a specific length

[Jshauk]

I tried typing a number in that is longer than 18 digits, it replaces all the numbers at the end with 0
I believe the problems lies within the highlighted code

Example:

[rxaviers]

Javascript Numbers can't hold integers bigger than Math.pow( 2, 53 ) (all numbers in JS are floats, more info). So, basically you can't get an integer bigger than 17 digits length with its full precision.

Globalize 1.x outputs the below, which I consider a regression compared to the previous output as shown in issue's description (I think the zero'ed result is better than the scientific notation one in this case, since user hasn't chosen so).

> Globalize.formatNumber(123456789012345)
'123,456,789,012,345'

> Globalize.formatNumber(123456789012345678901234567890)
'1.2345678901234568e+29'

Clearly, we'd need an additional big numbers library to handle that. Although, this should be optional.

@scottgonzalez, @jzaefferer, what do you think? Any ideas?

[scottgonzalez]

It's hard to say that this is a bug when JavaScript can't distinguish between these numbers.

123456789123456789123456 - 123456789123456789000000 === 0

Supporting a big number implementation is something we can consider, but I think we'd want to wait on that.

[jzaefferer]

Can we throw an error instead of returning an incorrect value? input too long, must be smaller then Number.MAX or something like that?

[scottgonzalez]

Number.MAX is massively larger than the point at which integers lose precision. I don't think it's possible to determine if the value that the user provided was accurately stored. For example, 9007199254740994 is greater than Math.pow( 2, 53 ), but is accurately stored. However, 9007199254740993 is smaller but isn't accurately stored.

[rxaviers]

This seems a very hard problem. I'm closing as won't fix. But, I am open for ideas and code suggestions.

[SlexAxton]

There is Number.MAX_SAFE_INTEGER now

[rxaviers]

Thanks for the input