Re: Parsing LDAP Generalized Time with DateTime::Format::ISO8601
On Sat, May 05, 2007 at 08:57:16PM -0700, Jonathan Leffler wrote: > I can't answer for the developers of DateTime::Format::ISO8601, but it is > not clear that they are required to support the notation, though I suspect > it would not be hard to do so, possibly by some specialized sub-class > (Date::Format::LDAP?) that exploits the majority of the ISO8601 code but > permits the LDAP Generalized Time notation. I can answer for the developer(s) of DateTime::Format::ISO8601. Thus far this module has only accepted a pretty strict interpretation of the standard. There have been a few requests to loosen to this up on the basis of "least surprise" as some people have expected it to parse things that "look" ISO8601 like. However, there are already a large number of swiss-army parsers that will handle ISO8601 "like" formats so it was decided that DateTime::Format::ISO8601 should only accept formats that are clearly allowed under the standard. This allows the module to be used as a validating parser. I've looked at RFC 4517 and in section 3.3.13 it states that it does not use a ISO8601 compliant format, "The LDAP-specific encoding of a value of this syntax is a restriction of the format defined in [ISO8601], and is described by the following ABNF: ...". The format that is defined looks fairly trivial to parse and I concur that it would be reasonable to create a Date::Format::LDAP module. Has anyone done this work already? -J -- pgpr5A0Xe249B.pgp Description: PGP signature
Re: Parsing LDAP Generalized Time with DateTime::Format::ISO8601
Ulrich Zehl asked: I need to parse date and time values that are encoded in the LDAP Generalized Time syntax. According to RFC 4517, Section 3.3.13, this syntax is "a restriction of the format defined in [ISO 8601:2004]". Following the syntax rules, a sample date and time may be encoded as 20070502074805Z (Note the lack of 'T' to seperate date and time.) Parsing this sample date and time with DateTime::Format::ISO8601 (version 0.06) using parse_datetime() fails, giving the following error message: Invalid date format: 20070502074805Z at test.pl line 499 Since I don't have access to the ISO standard, I cannot verify that the format as given in RFC 4517 is really standards compliant, but http://hydracen.com/dx/iso8601.htm, Section "Comined Date/Time Formats", seems to indicate it is. Given all this, I'd now like to know whether this format will be supported by some future version of DateTime::Format::ISO8601, or if I should contribute a seperate module to handle LDAP's Generalized Time syntax (which would be easy, since I have already have a prototype that satiesfies my own requirements). To which I respond: I have a copy of ISO 8601-2004, and I don't see where it standardizes the LDAP notation, though section 3.7 "Mutual Agreement" certainly would permit it between parties that mutually agree. The T for separating the date from the time seems to be required by the standard - you can miss out the other punctuation, but not that one. (I note in passing that the SQL standard uses a variation of ISO 8601 notation with a space in place of the T, but requiring full punctuation too.) The rest of the LDAP Generalized Syntax as illustrated is conformant. The ISO 8601-2004 (3rd Edn) standard supports sub-second times, incidentally; the original 1988 (1st Edn) standard did not; AFAIK, the 2000 standard did not support sub-second times either, but I only have a draft of that so I can't be sure. I can't answer for the developers of DateTime::Format::ISO8601, but it is not clear that they are required to support the notation, though I suspect it would not be hard to do so, possibly by some specialized sub-class (Date::Format::LDAP?) that exploits the majority of the ISO8601 code but permits the LDAP Generalized Time notation. -- Jonathan Leffler ([EMAIL PROTECTED]) STSM, Informix Database Engineering, IBM Information Management Division 4100 Bohannon Drive, Menlo Park, CA 94025-1013 Tel: +1 650-926-6921Tie-Line: 630-6921 "I don't suffer from insanity; I enjoy every minute of it!"
Re: Parsing LDAP Generalized Time with DateTime::Format::ISO8601
Ulrich Zehl wrote: >Since I don't have access to the ISO standard, I cannot verify that the >format as given in RFC 4517 is really standards compliant, It's conditionally compliant. The relevant paragraph of the standard reads: # 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. So an ISO 8601 parser shouldn't accept it by default. Where context dictates that a date-time representation is expected, it is unambiguous and so parsing it this way is acceptable. -zefram
Parsing LDAP Generalized Time with DateTime::Format::ISO8601
I need to parse date and time values that are encoded in the LDAP Generalized Time syntax. According to RFC 4517, Section 3.3.13, this syntax is "a restriction of the format defined in [ISO 8601:2004]". Following the syntax rules, a sample date and time may be encoded as 20070502074805Z (Note the lack of 'T' to seperate date and time.) Parsing this sample date and time with DateTime::Format::ISO8601 (version 0.06) using parse_datetime() fails, giving the following error message: Invalid date format: 20070502074805Z at test.pl line 499 Since I don't have access to the ISO standard, I cannot verify that the format as given in RFC 4517 is really standards compliant, but http://hydracen.com/dx/iso8601.htm, Section "Comined Date/Time Formats", seems to indicate it is. Given all this, I'd now like to know whether this format will be supported by some future version of DateTime::Format::ISO8601, or if I should contribute a seperate module to handle LDAP's Generalized Time syntax (which would be easy, since I have already have a prototype that satiesfies my own requirements). Regards, Ulrich
