Iso Date Format

ISO 8601 specifies an unambigous date format of YYYY-MM-DD.

Lots of advantages, like sorting is logical and it's not easily confused with other date formats.

Unfortunately you can't get hold of ISO standards for free, but there are plenty of web pages out there:

    http://www.cl.cam.ac.uk/~mgk25/iso-time.html
    http://www.saqqara.demon.co.uk/datefmt.htm
    http://serendipity.magnet.ch/hermetic/cal_stud/formats.htm

The good people at ISO have a heart for programmers: http://www.iso.ch/markete/8601.pdf Also, YYYY-MM-DD is only one of the formats in ISO 8601--check it out, there's a lot more... --OliverKamps

The problem with 8601 is that it is ill-defined. When you use, for example, a "reduced-precision" time format such as 1980-12-13T12 (leaving out the minutes, seconds, and fractions of seconds), it is undefined whether this refers to the interval of time from the start of that hour to the end of that hour, to the "instant of time" (an undefined concept, of course, and properly so) at the start of that hour, or perhaps to some specific precisely-but-unspecified time within that hour.

It also has "interval formats" and repetition counts, which are described in great syntactic detail but very little semantic detail: What precise set of seconds, for example, comprises the interval from 1999-12-11 to 1999-12-13T12? The standard gives no guidance on this point. Repetition counts are even worse: They specify how many times an interval is repeated, but not at what frequency. Ideally of course repeated intervals could be keyed by more than just time-between, which would be appropriate for describing electronics, but not for describing the occurrence of Halloween (there's a different number of days in every year), much less for describing "The first Wednesday after Easter, every year" (see DateOfEaster?).

Finally, 8601 is ambiguous to parse. Last year I wrote a validator for it, and discovered that there exist strings for which 8601 provides multiple possible interpretations. This is because 8601 formats were never intended to be recognized out-of-context: You have to already know the format you are expecting, to be assured of parsing it correctly. Though strictly there is no need for the standard to say this, since it should be assumed unless there's an assertion to the contrary, there must surely be programmers who have been taken in by it. I will dig up the examples I have of these ambiguities, and put them here. They don't come to mind immediately, but they're all just within the moment-of-time specifications, not even taking into account that the same syntax could in some circumnstances indicate a duration.

With all that said, 8601 is great for one use: Its normal format YYYY-MM-DDTHH:MM:SS.SSS... (and the reduced-precision versions of that), which alone among common date/time formats has the virtue that its proper sorting order is the same as its ASCII sorting order.

--DanielKnapp (delete signature at will)