For the love of god yes! a standardised date format is the only thing that really needs changing in json.
Re:JSON5 is a proposed extension to JSON
by TazeTSchnitzel on Sunday March 02, 2014 @10:10AM
(#7329345)
We already have a standardised date format, as such. A specific subset of ISO 8601:
> JSON.stringify(new Date())
"2014-03-02T15:08:55.309Z"
Re:JSON5 is a proposed extension to JSON
by hcarvalhoalves on Saturday March 01, 2014 @06:13PM
(#7326609)
What's the benefit of cluttering JSON with a constructor like new Date(...) when you can just standardize on ISO-8601 strings? JSON is not supposed to be eval'ed anymore.
JSON is JS. If I manually create a JSON document, it should also be valid in the context of code. And strings are not dates -- they are strings. That's why we have boolean and number literals.
So many other languages use JSON as a data format that keeping a weird constructor call in there would do more harm than good. Especially since you can keep the formatting code in your codebase and invoke that when you need to use that property.
We had a bug once when some logger output happened to get passed through JSON. The receiving code expected arrays of strings, but at some point one of the records happened to just contain a date. That ended up getting deserialised as a real Date object, not a string, which obviously broke. Using the same representation for different data types just seems to be asking for bugs.
The problem is that your code should have been expecting that field to be a string and nothing else, and other fields that contain dates to be a date and nothing else. In other words, if you're parsing JSON in this manner you need to apply some sort of schema to the data or have another field in the record denote the datatype. Anytime you're trying to auto-magically detect the datatype of the field, you're gonna have a bad time.
What is wrong with standard unix timestamps?
There's not a bijection between UTC time and "standard unix timestamps" due to leap seconds
if you encode TAI in a unix timestamp, this would be a solved problem, but due to the fact that you cannot encode the time zone in the "unix timestamp datatype", you'd also have to handle cases in which people chose another timezone.
This makes it good enough for storing data (it'd be nice if the size of the data type would be explicit) but suboptimal for interoperability with other systems that could be using a different standard
either you encode the timezone in a different field in your JSON, or someone (the JSON5 people?) could define a literal for timestamps like:
t+1393752828Z (this would also eliminate the ambiguity between timestamps and number literals)
Numbers, booleans, and null should be removed. What's wrong with using strings for every value?
Also, please add ISO-8601 dates (repeating my comment below)!
{ timestamp: new Date("2007-04-05T14:30Z") }