demerphq wrote: > On 9/2/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: >> The first is a single ISO 8601 datetime. The latter is an ISO 8601 date and >> an ISO 8601 time separated by a space. Two data fields instead of one. So >> it's all kosher, we just have to specify that's what we're doing. >> >> tapdate = isodate " " isotime > > Been a while since i looked at the spec closely, but I seem to recall > that this is actually one of the valid formulations for an iso 8601 > date/timestamp. The spec doesn't specify only a single format, but > rather a number of them. ISTR the 'T' is recommended but not > mandatory.
I had this argument with the DateTime::Format::ISO8601 author last year, which resulted in my doing a bunch of research, and lost. http://rt.cpan.org/Ticket/Display.html?id=23307 What you're thinking of is RFC3339 which is more describing a state of affairs on the Internet then anything else. At best it can be *omitted* (not replaced with a space) if all parties agree, which we can do because we're specifying the TAP format. But it cannot be replaced with a space and still called an ISO 8601 datetime. "NOTE: By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard." - ISO 8601:2004(E) Section 4.3.2 It all comes out effectively the same in the wash, its just a matter of how we specify it. Since RFC3339 isn't really a clear standard it's simpler to just say that a TAP date is an [isodate " " isotime]. We can even say that it can also be an [isodatetime], but recommend the former for readability, and everybody wins. Writing up a proposal on the wiki now. http://testanything.org/wiki/index.php?title=TAP_datetime -- Whip me, beat me, make my code compatible with VMS!
