Considering how there's almost no computers anymore with such limited resources that they can't store a string or convert to one, it's kind of crazy anybody bothers with the ambiguity of using numbers for the month.
The limited resource is not Compute Power, but Engineer time. Sure, you could ask someone to implement wrappers everywhere in the system so that the display is human-readable - or you could put one label somewhere clarifying the date format to readers.
Implement wrappers everywhere? Why can't they just write a single function that takes an ISO date a spits out a string (human readable) date? I'd put money down that such a function already exists in almost every library that deals with dates.
That's why I said "implement" and not just "write". The process of wiring in that existing function has non-negligible cost, as does keeping it updated/patched.
Sure, it should be pretty small - but it's non-zero. Is it worth it? That's a product decision.
It's written like 07 Aug 2013. It's consistent in character length, doesn't confuse internationals, doesn't take much space and is written exactly like being said around here. It's just not that great for file names.
Yeah, ok. Expanding the month to 3 chars does reduce potential confusion
I feel the need to be pedantic and point out that this is only necessary, however because of the ridiculous degenerate convention of MM DD YY(YY?) used by said country...
YYYY-MM-DD for everything. My PC clock, my phone and even my handwritten notes all use that format.
The only other acceptable format is military notation: DD MMM YYYY.
That's quirky - how is there anything logical about the military time format?
The 3 "M"s are not numerical, but indicate characters. For example 01 Jan 2023.
Considering how there's almost no computers anymore with such limited resources that they can't store a string or convert to one, it's kind of crazy anybody bothers with the ambiguity of using numbers for the month.
The limited resource is not Compute Power, but Engineer time. Sure, you could ask someone to implement wrappers everywhere in the system so that the display is human-readable - or you could put one label somewhere clarifying the date format to readers.
Implement wrappers everywhere? Why can't they just write a single function that takes an ISO date a spits out a string (human readable) date? I'd put money down that such a function already exists in almost every library that deals with dates.
That's why I said "implement" and not just "write". The process of wiring in that existing function has non-negligible cost, as does keeping it updated/patched.
Sure, it should be pretty small - but it's non-zero. Is it worth it? That's a product decision.
Hmm good point actually
Yes spreadsheet apps like excel do this. If I remember correctly MMMM would write the full month. January.
i just write mmmmmmm because you can never have too many m's.
It's written like 07 Aug 2013. It's consistent in character length, doesn't confuse internationals, doesn't take much space and is written exactly like being said around here. It's just not that great for file names.
Yeah, ok. Expanding the month to 3 chars does reduce potential confusion
I feel the need to be pedantic and point out that this is only necessary, however because of the ridiculous degenerate convention of MM DD YY(YY?) used by said country...