Could we solve dates first, then worry about comments and commas?
What’s missing?
ISO 8601 can represent a simple offset from UTC, but it can’t do a lot of the things that the IANA time zone database can do.
Adding an IANA library to the ISO8601 library (often part of the same lib) has so far solved that problem for me. I’m sure it starts struggling with dates before the early 1800’s though.
Also doesn’t work well if you’re dealing with relativistic effects I think.
It absolutely has every benefit you cite.
It's the only ISO spec I know the name of without having to look it up.
To be honest I think you're better off just not encoding the timezone in your main timestamp string at all and instead adding the full IANA timezone name (e.g. "Europe/London") in to a separate field. In sensible formats all the dates within a single JSON object or object will have the same timezone anyway, and to save bytes you can simply say in your spec "If absent, assume UTC".
Another problem with ISO is the specs aren't freely available, so people will generally guess or refer to old versions, drafts, or RFCs (like RFC 3339)
That means your json parser either will accidentally parse some strings as dates, or will have to be told which strings are (or even might be) dates, introducing a partial schema, or it will have to leave it to the application to convert strings into dates. Workable? Somewhat, but not ideal, just as not supporting numbers, and leaving string-to-integer-conversion to the application (after all, JavaScript will happily convert strings to integers in eval) would be ‘not ideal’.
Also, are you going to accept 2021-02-23T08:10:19Z, too? Leaving out the seconds, minutes,…? for interoperability, you would have to specify that.
The practical approaches are to represent it as time since the Epoch (in floating point) or a string where both sides somehow agree what "03/04/05" means.
All these are allowed according to the ISO standard.
If your data field represents a time (such as the selection of the time when a daily should recur each day), then you should use the ISO-8601 format with of a time.
If your data field represents a specific point in time (such as the time an action happened), then you should use the full representation of the date and time.
> you want the T separator or space?
When concatenating the date and time, the 'T' separator is used. Although, this is an implementation detail I've never had to touch myself, since every date library I've ever used has been able to format dates into an ISO format, and parse them from an ISO format without me having to consider the separator.
> Is time zone represented?
Again, this depends on what the data being represented fundamentally is. If it's a point in time that an event happened, yes. _Usually_ if you're representing a full date & time the answer is yes, you should represent the time-zone (I always serializing these dates in UTC and include the TZ).
The TZ should only be forgone if the data represents the abstract notion of a specific date and time, rather than a specific point in time.
To me (other than the "T" separator), these are all fundamental data questions, and not serialization questions. You need to know whether a field is a DATE, a TIME, a DATETIME and whether is a Zoned Date Time or a Local Date Time regardless of your serialization format.
ISO-8601 conveniently supports all these uses-cases and more.