Fixing JSON

I know this is from Tim Bray, one of the primary authors and/or maintainers of XML, RDF, Atom, and JSON, but while I too find some annoyances with JSON, I accept them because:

- JSON was never designed to be hand-editable. It's a lucky accident that it's more palatable to edit than XML, but there are other formats like YAML, TOML, and even .ini that fulfill that purpose.

- While JSON was originally envisioned as a subset of Javascript and intended to be materializable by JS eval(), this very quickly turned out to be a bad idea. Once we all switched to using parsers, there is no more compelling need to remain compatible with Javascript, other than human recognizability of syntax, and, y'know, compatibility with 'old' JSON; and

- JSON's greatest strength is that it has such a good impedance match to native 'abstract' data structures supported in just about every contemporary programming language: strings, numbers, lists, maps. When people say 'simple', I don't disagree, but I'm convinced they're actually referring to this feature. Adding additional types -- yes, even timestamps -- would break this property, as datetime handling in most languages leaves a lot to be desired.

The first language that comes to mind when I hear "datetime handling in most languages leaves a lot to be desired" is, slightly ironic considering JSON's origins, javascript. If you ever touch a date in JS you HAVE to pull in something like moment, full stop. JS Date is a steaming pile of shit.

To go on a tangent, Java8 dates are "awesome" if you've used Joda-Time before, for the rest of us it's a pain in the backside. I found myself spewing lots of code to just do Moment one-liners. That made me appreciate Moment much more, to the extent that I sometimes just eval a Moment script with Nashorn at times.

On the JSON part, I agree with everyone, my go-to language for most things is JavaScript, and I'm okay with dates in JSON. I think it's RFC3336 as everyone says (2016-08-20T21:12:26.231Z).

Date parsing could be better when moving across languages, but I mostly prefer sending around millis since Epoch. Considering that people mainly look at their JSON for debug purposes, anyone seeing 1471727663538 should recognise that it's a date.

Other commenters put it well that the author should rather propose a new language, JSON is fine the way it is. Typed successors like Protobufs don't have native date parsing, but I guess being binary, they take away the commas too. I'm comfortable hand-writing JSON or editing it when needed. Most text editors help out by highlighting errors and keeping track of parentheses.

To continue the tangent, perhaps you read my mind, because I believe that Java8 and Joda (and their ports) are the only two libraries that do datetimes properly, and every other one confuses and/or conflates human calendar and clock concepts with absolute point-on-a-timeline timestamps, and the like.

But this illustrates the point: datetime is hard and we don't agree, so even going so far as retrofitting a native RFC 3339 datatype into 'official' JSON is, in my opinion, too far.