> > The 15 is the string length. In this example, taken from the iCal > > format module, it checks the string length and parses based on that, > > since there are several valid iCal formats each of which is > > distinguishable based on length. > > Yeah. I got that =) I was just wondering what the applicability in > DateTime::Format::Builder would be.
Perhaps I shouldn't have been so lazy with my cut and paste of Dave's code. > I can see a use in, say, having an array of them. As in: try this first, > then this, then this, or fail. I agree. There are many possible ways of identifying a format so using a string length as the only option doesn't make any sense. I think your right with the array of hashes structure. > A hash could be useful if order isn't important, and for reporting a > name in some sort of verbose mode: An array would also conveniently deal with the case of more then one matching format (first one wins). > > I think what struck Joshua was the extreme similarity between this, > > the MySQL, and the W3CDTF module. Yep. > Theoretically, with a library of the things, you could write a > DateTime::Format::AttemptAll: > > my $parser = DateTime::Format::AttemptAll->new( > output => DateTime::Format::Excel->new ); > > my $dt = $parser->parse_date( $some_unknown_string ); > > print $parser->format_date( $dt ); > > where AttemptAll would create a bunch of the parser and try them in a > series. Not fast, but potentially effective. That could be dangerous. How do you deal with conflicts? I've had Date::Manip guess wrong at my date format and not find out until much later. I guess you could try all possible formatters and give a warn if more then one matches. > > If someone wants to work on a Builder module, that's fine with me. > > I'll be having a play. No guarantees. I'm a poor coder but I'll try to help. :) -J __
