> 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.
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.
> 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?
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".
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.