Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.
If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it correctly?
Just stick with ISO8601 strings.
You could make the same argument with numbers - there's no reason you couldn't just pass strings containing the number - but there's advantages to being able to distinguish between a string and a number when the schema is unknown.
The reason JSON doesn't have dates is simply because JavaScript doesn't have date literals. You can write new Date(...) in JavaScript, but allowing that in JSON would have opened a whole can of worms.
Why not "just stick with" decimal strings?
Is this a joke?
JSON numbers are....I don't know what they even are. JavaScript -- the originator of JSON -- can't support 64-bit integers in JSON. Nor can it support decimal fractions in JSON, despite JSON using decimals. And yet JSON numbers also aren'ty IEEE-754 floating point numbers, as they lack +/-Infinity and NaN.
JSON numbers are ill-defined and unique from every other "number" concept in any language or format.
Also, forget about the receiving side, you're also assuming that the sending side meant the date for the instant as at offset 0 instead of in their own timezone (which is probably how the instant is being displayed for them). From experience, that's not a safe assumption - witness any instant meant to mean "today's date here and now" derived from a now() call alone or truncated to have 0 time parts (in current time zone!) - I see that attempted a lot. Way too error prone especially when you don't control both sides.
If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a problem with that code, and has nothing to do with JSON or unix time.
The confusion might be coming from JavaScript incorrectly calling its instant representation Date, when it is actually quite a bit more precise than that.
Its also worth noting that you can't pick a time like 12:00 UTC and have it retain the calendar day in all time zones, because there are a few stray islands which are UTC+14 rather than UTC-10.
If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.
And if you're deep enough to worry about the cost of those extra bits, you probably want to have your own date type anyway, tuned for your exact problem.
const res = await fetch(url);
const data = await res.json();
It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.