Why did we even bother?
Why create ISO8601?
A new API, new this year, as an industry standard, has JSON fields like this
"nextAccessTime": "2023-May-18 04:43:00+0000 UTC"
I mean, pick a lane, why "+0000" and "UTC"?
Why "YYYY-MName-DD" FFS, that is not *any* standard in RFC or ISO?!
I just don't know how they could have come up with that in any sane way.
The xkcd "cat" format would be saner!
(FYI, it is TOTSCO)
*Picks up Magic 8 Ball*
ReplyDelete"Is ToTSCo going to create a big mess several years after it has launched"?
*Shakes ball*
> Signs point to yes
I think I'm broken, as I can't bring myself to put a year before the day. It has to be DD/MM/YY (or YYYY) - least significant measure of time first - or I'll be triggered hehe :)
ReplyDeleteeeeew
ReplyDeleteI will never understand why developers have such an aversion to IS08601, and insist on creating their own idiotic date formats.
ReplyDeleteBoth the FlexLM and RLM licensing systems require abbreviated month names instead of numbers in their license files (which in the past has caused problems with non-English customers). We even had a developer propose an internal date scheme which LOOKED like ISO8601 but swapped the month and day values for absolutely no reason (breaking the lexicographic sorting), then fob off criticism with "It's just an internal file naming scheme, who cares?!?!".
It's the worst possible kind of Not Invented Here. It's like somebody looked at a wheel, and said "let's invent our own version of that, but we'll make it square".
Nearly spat my drink out at "FYI, it is TOTSCO". I could have guessed..
ReplyDeleteUsing short-month-name disambiguates MM-DD vs DD-MM.
ReplyDeleteYes, but no need when using ISO8601.
DeleteYYYY-MM-DD works
People do DD-MM-YY, DD-MM-YYYY, MM-DD-YY, MM-DD-YYYY, but nobody does YYYY-DD-MM do they, so what ambiguity does this disambiguate exactly?