JSON doesn't have types like that so that doesn't make sense. It supports a few simple primitives and that's what makes it extensible and gives it it's power. Types like timestamps should come from the language or library that produces JSON only.
Semantically timestamp is a product type imho, so the logical representation in JSON would be with an object: {"year" 2022, "month": 4, "day": 1, ...etc}. The fact that nobody does that and instead serialize it to ISO-style string is telling about json.
I see it as a sign that JSON is not that great for structured data if people prefer to pack their datetime structure into a string rather than the more native object format.
Oh, gotcha. Well, I definitely agree it would make more sense for it to be an object like you mentioned but I think it's probably more explainable by the fact there is native support for ISO date / time strings in most programming languages, making it just as easy to parse a date or time from a string value and having the added advantage of reducing the size of the payload on the wire. I could be wrong
"All" programming languages have some concept of a timestamp, or at the very least can manage a coherent mapping. Adding timestamp to JSON would introduce no portability issues. It would reduce portability issues by standardizing a commonly used data type.
"My programming language doesn't have timestamps" is not a real problem.
"Ten thousand stupid date formats which are all ambiguous with either numbers or strings" is an actual problem that people bang their heads into every day.
What are you talking about? JSON is a format for exchanging data of any kind. It doesn't have types beyond a set of primitives to that it can remain as a _notation_ that allows you to pass any type you define and want to send.
Nothing is stopping any library or language from implementing an object or String for dates or times (or both) and tons of them have done so.
It wouldn't be JSON's place at all to start defining anything like that.
Nonsense. JSON (or "JSON++") can define any arbitrary primitives. Someone already made the arbitrary decision to have boolean values instead of "true" and "false" strings; having timestamps is merely another arbitrary decision.
You seem to believe that the primitives in JSON are some sort of platonically pure form. They were merely a choice, and a that choice could be improved.
https://www.json.org/