[allenbrunson]

argh! i can't believe people are still arguing about whether we should do MM/DD/YYY or DD/MM/YYYY or anything similar to that. here's how you should write a date that you are going to show to a user:

Jan 11 2016

if you accept that premise, it doesn't matter (much) what order you put the elements in, because none of them can be confused with any other. a word is a month, a one- or two-digit number is the day of the month, a four-digit number is the year.

i feel the same way about websites that expect me to input phone numbers, credit card numbers, social security numbers, etc without punctuation or spaces. why are you making this my problem? if your backend requires that, then strip out everything i typed that wasn't a digit and do your own formatting. geez.

[kazagistar]

That sounds a lot harder to localize, if local month names have different abbreviations.

[allenbrunson]

A programmer's job is to make things easier for the user, not for himself. That's why we get paid the big bucks.

[kuschku]

Don’t you mean 11. Jan 2016? ;)

[allenbrunson]

that way would work fine, too. i can look at that and tell what date we are talking about at a glance.

the real problem is displaying both the month and the day of the month as one- or two-digit numbers, which leads to ambiguity. display the month as a three-character string, and the year as a four-digit number, and we are all on the same page again.

[kuschku]

Actually it doesn’t, there’s standards for that.

YYYY-MM-DD

DD.MM.YYYY

MM/DD/YYYY

Notice the separators. Except for parts of Japan and Australia, these are international standards and used everywhere.

[allenbrunson]

it's pretty obvious that, if those standards were being followed all the time, we wouldn't be having this conversation.

i am talking about an ad hoc, fairly simple thing one can do, if one is writing user-facing code. it's a rule i follow, and i offered it up as something other people might want to try as well.