Fixing JSON

There is already a canonical way to have timestamps: encode them as defined in RFC 3339.

Done.

The proposals add nothing to JSON and don't make sense. I mean, screwing up with the language just to add a very specific data type that is used in only a specific corner case that isn't even supported in the use case that's provided as an example? Nonsense.

If you are not suggesting that timestamp values be wrapped in quotes, then wouldn't you have to worry about every existing parser out there tripping on them?

That's not canonical at all. It's not even a de facto use of timestamps in JSON; most specifications I see call for ISO 8601.

> Done.

Well no, not done, because you then have to wrap it in a string, which essentially hides it from the JSON parser altogether and moves responsibility for parsing it out of the JSON parser into your application. As far as the JSON parser is concerned, it could be any old string, not a timestamp.

> a very specific data type that is used in only a specific corner case

I don't see how you can call timestamps a corner case – the article says "Among the RESTful APIs that I can think of, exactly zero don’t have timestamps." – and my experience is the same. Pretty much every API I've worked with has used timestamps in some form or another. They aren't a corner case at all – aside links, they are probably the most common data type without direct support in JSON.

Nonsense. ISO 8601 is an ISO standard that defines representations of dates and times.

Date and time representations aren't timestamps.

RFC 3339 is based on ISO 8601 but is designed specifically to handle timestamps by including provisions that tackle interoperability problems that ISO 8601 does not handle.

> Well no, not done, because you then have to wrap it in a string

Nonsense.

JSON is just the languge that is used as a superset for other domain-specific languages. How the other language defined (and parsed) isn't handled by the JSON parser, obviously.

Considering Tim Bray's example, If a domain-specific language specifies that a "Capture time" string is followed by a string storing an RFC 3339 timestamp, that's precisely what the parser for the domain-specific language is expected to parse. The document remains valid JSON, and the domain-specific language remains valid.

> I don't see how you can call timestamps a corner case

Because it is. It isn't a primitive data type, nor is it required to implement generic data structures. Hell, some programming languages don't even support any standard date and time container or aggregate data type. Timestamps are a very specific data type whose application is limited to very specific corner cases that are already handled quite well by other means.

So in other words, what I'm saying isn't "nonsense" at all, and they aren't fundamentally different things as you claim – you just prefer a standard that you think is better?

In any case, you're getting away from the point there. The point was not which standard was better, the point was that RFC 3339 is not canonical.

> > Well no, not done, because you then have to wrap it in a string

> Nonsense.

It's not nonsense in the slightest. You can't put an RFC 3339 timestamp into JSON without wrapping it in a string, at which point it is no longer part of JSON. All JSON sees is a string, not a timestamp.

> The document remains valid JSON, and the domain-specific language remains valid.

I never said that it wasn't valid JSON, my point was that as far as a JSON parser is concerned, it's a string, not a timestamp, so parsing a timestamp has to be handled by your application not the JSON parser.

> It isn't a primitive data type

When the subject of discussion is whether or not it should become a primitive data type, that's circular logic.

> nor is it required to implement generic data structures.

No, but it is required to implement a vast number of JSON-based APIs.

> Timestamps are a very specific data type whose application is limited to very specific corner cases

The "very specific corner cases" being every single RESTful API the author can think of? This is an incredibly common use case, I don't see how you can argue that it's a corner case when it's practically ubiquitous.

It's nonsense, because a timestamp isn't a date representation. This was already demonstrated. I don't understand why you decided to ignore this.

> The point was not which standard was better, the point was that RFC 3339 is not canonical.

No, the point is that the ISO standard you've quoted doesn't define timestamps. Hence, the example you provided to refute what I've said was nonsense.

> You can't put an RFC 3339 timestamp into JSON without wrapping it in a string

...and you can't encode a date without representing the year as a number, the month as another number, the day as anohter number, etc etc etc.

You, somehow, miss the point that a primitive data type is not required to represent timestamps.

In fact, you can represent timestamps in JSON by defining an aggregate type.

Timestamps as primitive data types doesn't make any sense if it's possible to use the types that are already available to represent it.

> my point was that as far as a JSON parser is concerned, it's a string

Somehow, you don't understand that JSON is only the superset language, and that JSON-based domain-specific languages represent specific subsets of JSON obtained by imposing other parsing rules.

> When the subject of discussion is whether or not it should become a primitive data type, that's circular logic.

You somehow already forgot that this particular data type is already representable by using another primitive data type.

> No, but it is required to implement a vast number of JSON-based APIs.

No, it's not.

Wrap it in a string. Done.

If that's too hard to do, just specify an aggregate data type.

Is it that hard to understand?

> The "very specific corner cases" being every single RESTful API the author can think of?

Somehow, no RESTful API was barred from being implemented in JSON because of this corner case.

I suspect you are, somehow, confusing "convenience" with "necessity".