Re: Rough ISO8601 parser ready...
> I'm inclined to say completeness is more important than speed in this > case. Optimizations can always be done later anyway. They'll both be complete for Date + Date and Time formats. Just times can't be done with DT. The difference is in supporting recurrences, durations, and the user being able to specify which formats to parse. -J --
Re: Rough ISO8601 parser ready...
On Fri, 20 Jun 2003, Joshua Hoblitt wrote: > We are thinking about having two different modules. Or I'm willing to > throw mine away if it's just going to be superfluous. > > DateTime::Format::ISO8601::Complex > DateTime::Format::ISO8601::Simple > > The question is should there be a DT::Format::ISO8601 module? And if so > which module should it be. I'm more or less indifferent as which way to > go. Ben's module will cover much more of ISO8601 then mine. I'm inclined to say completeness is more important than speed in this case. Optimizations can always be done later anyway. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough ISO8601 parser ready...
On Sat, 21 Jun 2003, Iain Truskett wrote: > * Ben Bennett ([EMAIL PROTECTED]) [21 Jun 2003 14:18]: > > I have made my rough ISO8601 parser available at: > > http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz > > Could you check it into the CVS please? A name needs to be settled on first. Ben and I have had some discussion and we've taken completely different and incompatible approaches. My parser only does Dates + Date/Time formats and although very simple in scope it should be pretty fast with length matching. Not to mention I didn't finish it two months ago like I should have. Ben's module has a very large scope and should eventually do recurrences/durations (pretty neat) although there is some startup overhead it could be just as fast. We are thinking about having two different modules. Or I'm willing to throw mine away if it's just going to be superfluous. DateTime::Format::ISO8601::Complex DateTime::Format::ISO8601::Simple The question is should there be a DT::Format::ISO8601 module? And if so which module should it be. I'm more or less indifferent as which way to go. Ben's module will cover much more of ISO8601 then mine. -J --
Re: Rough ISO8601 parser ready...
On Sat, 21 Jun 2003, Ben Bennett wrote: > - Module name not settled yet What other name would you use? DT::F::ISO8601 seems pretty logical to me. Why not check it in with this name? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough ISO8601 parser ready...
* Ben Bennett ([EMAIL PROTECTED]) [21 Jun 2003 14:18]: > I have made my rough ISO8601 parser available at: > http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz Could you check it into the CVS please? cheers, -- Iain.
Rough ISO8601 parser ready...
I have made my rough ISO8601 parser available at: http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz Since this is a rough first release there are huge things wrong with it. An incomplete list is: - No documentation - Module name not settled yet - Only parses Dates (no times, recurrences or durations... yet) - Code is littered with XXX indicating areas of further thought - Code is littered with debug stuff - Code should be much cleaner before release - The interface is nowhere near done - Needs more tests (and tests of failure) - Error handling doesn't exist What it does do at the moment: - Parses any valid ISO8601 date - Allows you to pick which format categories to apply (but the interface is awful!) - Does selection by variable length (8+ characters) - Reasonably efficient algorithm for picking which formats match the user's categories - Test suite works now (and is passed completely) If you want to play with this either check out the test suite, or use the following line as a basis: PERL5LIB=lib perl -MDateTime::Format::ISO8601 -e 'print DateTime::Format::ISO8601->parse_datetime(shift, shift)->datetime(), "\n"' 2003W011 The optional second argument is the formats to use. The valid formats are: C: Complete (fully specified date) R: Recuced Precision (less significant items are dropped) T: Truncated (current items implied) B: Basic (no separators) E: Extended (with separators) X: Expanded (extra years) O: Ordinal date (day count from year) W: Week date (day count from year) The default is to try all of them (XWOTCREB). You must always pass in E or B and C or R since each format has those types. So if you only wanted to use Complete Basic items, pass in "CB". -ben
