[pfooti]

literally the only use case I see here is dates. Like everything else I can infer the type of the field based on its contents. "boolean": false, no kidding. "event_ts": 1223349483, is that an index number or milliseconds since epoch or what? Well, probably ms since epoch, but my one gripe about json is that there's no good way to push dates without domain knowledge (anything whose property name ends in _at or _ts gets converted? all numbers in a certain range get converted?)

[geezerjay]

> literally the only use case I see here is dates.

{ "date": "1937-01-01T12:00:27.87+00:20" }

As you can see, JSON doesn't stop anyone from using RFC3339 to encode dates.

[pfooti]

Sure, and then on the other end of the connection you need to say: newThing.date = new Date(newThing.date), or else it'll deserialize as a string.

What I'm getting as is that a date gets serialized into JSON as either a string or a number, depending on who wrote the toJSON method, and that the consumer of that JSON needs knowledge about the schema of the data in order to properly deserialize it.

[geezerjay]

> Sure, and then on the other end of the connection you need to say: newThing.date = new Date(newThing.date), or else it'll deserialize as a string.

Only if the software running on the other end does not support your data format.

Meanwhile, HTML uses string attributes to declare languages, and no one ever complained that browsers may interpret the lang tag as a string.

[pfooti]

I feel like we may be talking past each other there. Imagine:

const data = { name: 'foo', time: new Date('05 October 2011 14:48 UTC') }; const data2 = JSON.parse(JSON.stringify(data));

typeof data.time === 'object' typeof data2.time === 'string'

What I'm getting at is: JSON.parse and JSON.stringify convert date objects into strings. While dates are not javascript primitives, there are no other things I can think of that you'd use to hold state that aren't preserved across JSON.parse(JSON.stringify(thing)) boundaries. If you want to write a JSON handling API endpoint, you can pretty easily process all the incoming data and deal with it in a zero-knowledge fashion, but if you want to properly deal with dates there, you're going to have to add knowledge to the parser receiving the JSON object.

This is a complaint I have about JSON in general, as a method for serializing data for transport across the wire. XML is an annoying format to work with, but at least metadata was possible (of course, dealing with dtds or other metadata formats basically made zero-knowlege parsing impossible anyway, you just wrote a meta-parser that used the dtd to encode the knowledge).

If, instead of '2011-10-05T14:48:00.000Z', or 1317826080000, we took a page from binary / octal / hex numeric representations, and defined a date prefix - 0xcoffee is a number, why can't Dx1317826080000 be parsed by JSON.parse as a date?

I mean, I know why. But it's still annoying that, when receiving data from an API, I basically can treat everything in the API as fine as written, except that I have to go in and fiddle date strings into date objects.

[dolmen]

With TJSON the receiver will have to know about TJSON deserialization. So how is it an improvement?