That sounds like you ran into problems when deserializing a number value from JSON, which then got slightly changed due to floating point shenanigans. That’s technically not JSON’s fault. JSON numbers aren’t IEEE754. They’re just numbers. It’s only the deserializers that usually choose to represent JSON numbers as floating point values.
A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. […]
A fraction part is a decimal point followed by one or more digits.
Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
Yeah, the problem wasn’t that there were json numbers, it was that they were being parsed and deserialized wrong. And boy, were they being parsed and deserialized wrong in a lot of places.
It’s just one extra arg in the parsing method to fix it, just a pain in the ass rebuilding half a data warehouse to fix the existing data.
That sounds like you ran into problems when deserializing a number value from JSON, which then got slightly changed due to floating point shenanigans. That’s technically not JSON’s fault. JSON numbers aren’t IEEE754. They’re just numbers. It’s only the deserializers that usually choose to represent JSON numbers as floating point values.
Quoting https://www.rfc-editor.org/rfc/rfc8259#page-7
Yeah, the problem wasn’t that there were json numbers, it was that they were being parsed and deserialized wrong. And boy, were they being parsed and deserialized wrong in a lot of places.
It’s just one extra arg in the parsing method to fix it, just a pain in the ass rebuilding half a data warehouse to fix the existing data.