4 ms·

US date format deserves a special place in hell under any circumstances.

• Pxtl 12y ago
  Seriously. It's the best here in Canada where there is no consistent convention between Euro-style or US-style dates. Officially Canada uses Euro-style dates, but we're so intertwined with the USA that it's basically random. yyyy-MM-dd or die.
  • bushido 12y ago
    It's definitely random. I remember having to fill a Canadian form (govt.) that had three date formats(in the same form), i.e.: dd-mm-yy mm-dd-yy yy-mm-dd
  • tempodox 12y ago
    In other words, make RFC 3339 mandatory for everyone internationally. And everyone has to add time zone info to dates, or just use UTC (marked as such).
• psychometry 12y ago
  I don't think the European dd-mm-yyyy is any better, since there's no way to tell whether it's April 6 or June 4. yyyy-mm-dd is the only way to go.
  • cs02rm0 12y ago
    04-06-2014 is the 4th of June. 06-04-2014 is the 6th of April. I can get this right every time without learning every date parrot fashion, so there must be a way to tell. I'm not sure how largest -> smallest component (exclusive of any more fine grained units) is any more logical than smallest -> largest.
    • dragonwriter 12y ago
      Largest->smallest is the order the digits in the components are written in, so doing the larger structure the same way as the smaller components is more consistent. yyyy-mm-dd is only more unambiguous (as opposed to internally consistent) than either dd-mm-yyyy or mm-dd-yyyy because there is no other common 4-2-2 digit combination, while both of 2-2-4 digit combinations are common enough that ambiguity, especially with an international audience, is certain. yyyy-MMM-dd (with month name or name abbreviations) is probably the least ambiguous (even slightly better than ISO 8601 on that point), but its also language-dependent, which is a big downside, and doesn't sort well as a string (which is a downside in automated applications, though perhaps not as much for human reading). ISO 8601 isn't perfect, its just better than most of the alternatives and adopted as an international standard.
    • psychometry 12y ago
      You "get it right" because that's the only format you see wherever you're from. It reality, it's impossible tell without context, which is why both are inferior formats. yyyy-mm-dd has the additional benefit of being sortable as text, so it's better than dd-mm-yyyy even if you ignore the obvious ambiguity.
  • dspillett 12y ago
    d-m-y at least has the logic of the number scales being in order, though if you add the time in the usual place (after) this falls down. UK here, and unless otherwise specified I write dates in yyyy-mm-dd. That order just makes sense: it is unambiguous (well, usually, see below) and sorts nicely in string form. One extra annoyance I've experienced is SQL Server: if your user language setting is set to "English (British)" instead of just "English" (and by "English" they mean "use American standards where there is a choice"), as well as switching which way it interprets strings of the form NN-NN-NNNN it also switches how NNNN-NN-NN is read so it expected YYYY-DD-MM. This makes no useful sense at all, as far as I know no one in the world uses YYYY-DD-MM for anything... (of course what should be done for string->date conversion is explicitly calling CONVERT() with the code for ISO8601 instead of letting it guess your string format, that was it always gets it right, but in code not controlled by us there are occurrences of just throwing the string at CAST() or letting it be implicitly cast and letting SQL Server guess the format)