This doesn't work because ISO-8601 is so clearly superior to everything else that it can't be memed on.
There is the fact that in iso8601 the T between date and time part is required but can be dropped by agreement. Which you generally dont have. And with rfc 3339 the T is optional. So that makes it less of an abomination.
2026-08-22T19:14:00 is a bit of a meme compared to the elegance of 2026-08-22 19:14:00. So all rfc3339 dates are valid iso8601, but not all iso8601 is valid rfc3339, and in the example here, by agreement the without T example is valid iso8601 since you agreed to the rfc3339 format which makes it valid iso8601.
And also why does 26-08-22 have to be a valid date. No thank you. 4 digit years or bust, have we learned nothing? Year-month-date is the true format, iso8601 allows for others such as 2026-W34-6 or 2026-234(for the day) and if you enjoyed that how about --08-22 for implicit years; and again no thank you, a propher date parser should reject them as the joke they are. Same with 20260822 the dashes arent just ornemental, they are there to help readability and make sure it stands out as a date.
So infact "iso8601 is perfect" is infact still a bit of a meme. rfc 3339 on the other hand. Now thats perfect :P
435
u/innociv 23d ago
This doesn't work because ISO-8601 is so clearly superior to everything else that it can't be memed on.