Re^3: What is a stringwise operator?

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 ]

Comment on Re^3: What is a stringwise operator? Download Code

Replies are listed 'Best First'.
Re^4: What is a stringwise operator? by jhourcle (Prior) on Feb 25, 2008 at 18:34 UTC
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'`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: What is a stringwise operator?
by jhourcle (Prior) on Feb 25, 2008 at 18:34 UTC

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'

[reply]
[d/l]
[select]