4 ms·
Lots of empty promises: * int: arbitrary size integers * decimal: arbitrary precision, base-10 encoded real numbers * timestamp: arbitrary precision date / t
by user5994461 6y ago
Lots of empty promises:
* int: arbitrary size integers
* decimal: arbitrary precision, base-10 encoded real numbers
* timestamp: arbitrary precision date / timestamps, with ISO 8601 format "2019-05-01T18:12:53.472-0800".
So exact same drawbacks as JSON basically:
* Large integers will be casted to 32 or 64 bits in most languages no matter what.
* Arbitrary decimal will be casted to float or double as well.
* ISO timestamps are not well specified when it comes to millisecond, microsecond and timezone.
- lilyball 6y agoThis is awfully negative. JSON explicitly does not declare the represented range of floats or integers, and doesn’t have a distinct arbitrary-precision decimal type. I haven’t read the Ion spec, only the description, but since it’s advertising arbitrary precision, presumably any implementation that does not support that is not a correct implementation at all.
- user5994461 6y agoIn practice that means having (or adding) support for arbitrary numbers and decimals in the languages/platforms they want to cover. I am skeptic they would do that in C for example.
- lilyball 6y agoThe C implementation bundles the ICU decNumber library for decimal numbers.
- rswail 6y agoAny of the elements of an ISO 8601 time element can have decimal fractions added to any number of digits. But only the lowest element (according to Wikipedia because I don't have the actual standard in front of me). But you can definitely have a timestamp of 2020-07-23T12:37:55.758145Z The standard acommodates timezones as offsets from UTC, because it's a representation of a timestamp, not a local time at a particular geographical location. So things like daylight savings time periods are not relevant.