* Supports birthdays for people older than 52
* Reliable after 2038
* Supports leap seconds
* HTML date/time spec is a subset
* String collation order matches temporal order
* Excel
Computers are the main consumers of APIs, and ISO 8601 is far from machine-readable.
For example, in Elixir, DateTime.from_iso8601/1 won't recognize "2022-03-12T07:36:08" even though it's valid. I had to rewrite a chunk of Python's radidjson wrapper to 1-9 digit fractional seconds (1).
I'm willing to bet 99% of ISO8601 will fail to handle all aspects of the spec. So when you say "ISO8601" what you're really saying is "our [probably undocumented, and possibly different depending on what system you're hitting] version of the ISO-86001 spec."
(1) https://github.com/python-rapidjson/python-rapidjson/pull/13...
No.
The specific profile of ISO8601 that should be used to express timestamps in an API is that defined in RFC3339.
Choosing to use a half-baked parser is a separate matter.
Edit: a relevant link
A ven diagram very cool
2. The ISO date format is "big endian" by default, which makes it trivial to chunk and compare just specific date parts. Want all events that occurred on the same (UTC) date? Just do dateField.substring(0, 10). Everything in the same year? dateField.substring(0, 4).
Past dates should always be in UTC, for the same reason - timezone rule changes are sometimes even retroactive.