I really (really really) wish they'd added a way to represent dates. Dates were left out of the original JSON spec since javascript doesn't define a syntax for date literals. You have to execute the Date() constructor to make them. Since JSON was supposed to be a subset of non-executing javascript, dates were excluded from JSON.
That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.
The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.
If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.
No, not all browsers, and not all of ISO 8601. Safari only added ISO 8601 Zulu parsing in the last few months, and IE only at version 9. Neither support explicit timezones yet. Which means there's still a large population of browsers that will choke. As I said, date parsing is a mess.
In any case, my general point still stands: dates are the only "data" type (i.e. not a function, regex, etc.) which is not supported by JSON. So even if there were a usable universal serialization format, you'd still need to post-process the results of the JSON parser to convert the strings into dates.
That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.
The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.
If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.