Jordan Tucker

Additionally, I think it's best to give developers the option to parse JSON5 documents even if they contain `NaN`. Often times, developers do not have control over what a JSON5...

Thanks for your input. There was a discussion about standardization in https://github.com/json5/json5/issues/190, so you may find some of that interesting.

Thanks for the suggestion. JSON5 already intrinsically supports arbitrary-precision integers, as there is no limitation on how large a number can be in a JSON5 document. In fact, JSON5 has...

I created [a replacer function and a reviver function](https://gist.github.com/jordanbtucker/d48b826aa9f4e868f8d406d84fa10526) for BigInt that both work with JavaScript implementations of JSON and JSON5. It converts BigInts to and from strings. ```js const...

I would not say that JSON's lack of numeric data type indicators is a deficiency. It's a feature that makes JSON platform agnostic and interoperable. As I already explained, JSON...

I like this idea. However, instead of ISO 8601, I would say that dates should be converted to UTC and represented as strings in Internet Date/Time Format as defined by...

I added the following section to a new [v1.1.0 branch](https://github.com/json5/json5-spec/tree/v1.1.0). # Dates and Times It is recommended that JSON5 generators convert date and time values to Coordinated Universal Time (UTC)...

@tracker1 I'm hesitant to have parsers automatically convert date-like strings to dates. Strings would no longer be just strings, but they'd also be maybe-dates. And if the platform doesn't have...

I don't think it's a good idea to start treating strings as maybe-dates, especially when it breaks backward compatibility. On another note, I think putting non-printable characters in strings would...

If parsing strings as maybe-dates is a parser option, then I don't think it belongs in the syntax.