I like ISO format because then alphabetical order corresponds to chronological order.
Y-M-D and D-M-Y both have their advantages. Unfortunately my compatriots have standardized on M-D-Y, a convention that has no advantages that I can think of.
I've always found M-D-Y apt for many use-cases, because I often know exactly which year is being referred to - I just need to know the month and day. With M-D-Y, that information is immediately presented. It seems like a decent compromise.
My favorite format is YYYY-MMM-DD. That is, year, 3-letter (english) month, day (i.e. 2013-Nov-29). Only works for people that know the english names for dates, but eliminates ambiguity about which is the day and which is the month.
> so you get to the most important information first.
Very debatable. I've always found YYYYMMDD to be the most pertinent format as it gives you the "most important information first". As in, DD is unusable if you don't know the month, and the month is unusable if you don't know the year.
I like to picture a world where everyone use YYYYMMDD, the Metric system and English for technical terms (I'm from France and I hate when we invent new terms for technical terms).
Most humans know what month and year they're dealing with already, and look to a date display to inform them of DD vastly more often than they look for MM, more often than they look for YYYY.
When dealing with data processing, the concerns are obviously different. But then it barely matters which order you use anyway.
I usually just use HL7 datetimes YYYYMMDDHHMMSSFFFF since it's mostly iso compatible and more importantly allows for varying levels of unknown values.
You may know what month something happened to you but you may not know the day in which case you would just write 201308 which is a perfectly valid date. You may know what day and what hour someone was born but you may not know the minutes or seconds (ex. 2013080506).
By using it, there is no ambiguity because the year signals the order of values. It also sorts better than any of the other methods.
You have to ask yourself in what cases do you have to write a date, or do you have to read a date.
For most "real life" cases I could find it was smarter to put YYYY first. And for an impressive number of cases, the day of the month didn't really matter and could then be omitted more easily.
You get the 2nd shortest duration first (tens of days) then the shortest (days) then the fourth shortest (tens of months) then the third shortest (months) etc
With the ISO standard every character symbolises a larger duration than the one that follows, so to get a strictly increasing order you have to reverse the string entirely - today would be 92-11-3102
20 comments
[ 2.6 ms ] story [ 101 ms ] threadToday could also have been a "perfect prime day" if MM, DD, YY and YYYY had been prime (in addition to the above). But it's not the case...
11 -> is prime
29 -> is prime
13 -> is prime
2013 -> not prime (3 x 11 x 61)
Too bad! We will have to wait another 16 years before we have a perfect prime day...
Y-M-D and D-M-Y both have their advantages. Unfortunately my compatriots have standardized on M-D-Y, a convention that has no advantages that I can think of.
Very debatable. I've always found YYYYMMDD to be the most pertinent format as it gives you the "most important information first". As in, DD is unusable if you don't know the month, and the month is unusable if you don't know the year.
I like to picture a world where everyone use YYYYMMDD, the Metric system and English for technical terms (I'm from France and I hate when we invent new terms for technical terms).
When dealing with data processing, the concerns are obviously different. But then it barely matters which order you use anyway.
You may know what month something happened to you but you may not know the day in which case you would just write 201308 which is a perfectly valid date. You may know what day and what hour someone was born but you may not know the minutes or seconds (ex. 2013080506).
By using it, there is no ambiguity because the year signals the order of values. It also sorts better than any of the other methods.
For most "real life" cases I could find it was smarter to put YYYY first. And for an impressive number of cases, the day of the month didn't really matter and could then be omitted more easily.
You get the 2nd shortest duration first (tens of days) then the shortest (days) then the fourth shortest (tens of months) then the third shortest (months) etc
With the ISO standard every character symbolises a larger duration than the one that follows, so to get a strictly increasing order you have to reverse the string entirely - today would be 92-11-3102