It works, so long as each element is 0 padded, and you're using consistent delimiters between the two items to be compared. The following won't work:

'2004-9-1' lt '2004-10-1'
'2004/09/01' lt '2004-09-01'
[download]

I typically get around the second issue by stripping out all non-digits, and then comparing. The first one I haven't found a simple one-line solution for, as I get stuff that's both delimited and run together. If it was always delimited:

sub normalize_date { return join( '', map { sprintf( '%02i', $_ ) } sp
+lit (/\D+/, $_[0]) ) }
sub compare_dates { return normalize_date($_[0]) cmp normalize_date($_
+[1]) }
[download]

hmm ... I guess this _would_ work for me, as the non-delimited stuff I get is always 0 padded.

ISO 8601 Date and Time Specification Format

2007-10-05 11:34:22
[download]

Dates in the format above are inspired by the ISO Date and Time Specification Format, ISO 8601 for short. (Often, the Zulu is omitted, a minor faux-pas in ISO terms.) The benefits are obvious: since the digits are already in most-to-least significant order, the strings sort naturally in chronological order; also, by using standard separators the included or omitted fields can be parsed with confidence.

--
[ e d @ h a l l e y . c c ]

Order date/time from largest to smallest unit has been around a _lot_ longer than 8601 (1988) . However, the formatting being discussed will _not_ work generically for 8601 dates, as there are so many acceptable formats that it would NOT be reliable.

8601 includes formats for DOY (day of year) and week of year:

'2004-002' vs. '2004-W01-03' vs. '2004-01-01'

Straight string comparison (without stripping delimiters) would also fail on comparing the mentioned format to an 8601 datetime, as they use a 'T' between the date and time portion, and the delimiters are optional for some formats:

'2004-01-01T01:30Z' vs '20040101T0130Z'

You also can't blindly strip delimiters and assume things are in the right order, as there's options for repetition and duration:

'R3/2008-01-01P1D' vs. '2008-01-01P3D' vs. '2008-01-01/03' vs. '2008-01-01T00:00Z/03T24:00'

But, the biggest (and most encountered, in my case) problem is that until the 2004 revision of 8601, it was acceptable to use 2 digit years, which meant that 6 digits without delimiters was YYMMDD, not YYYYMM:

'200101' vs '2010-01'