I want to preserve the revision history of my tree so the move to SF won't be until next week.
What really needs to be done is a lot more tests. I'm considering a framework for building tests. > I have some additional functionality that I think is critical: > 1) The ability to say which pieces of the ISO spec are applicable > (otherwise you can not tell the formats with leading -s apart from > the ones with expanded years). Also you need to be able to > specify the number of additional years The simple solution is parse_time - a better one is coming. > 2) Return information about the matching format so that you can tell > which information is ommitted in the reduced formats. (e.g. I > want to be able to tell the year 2003 apart from Jan 1 2003. I agree but we don't have attributes for DT yet. > Then some other information that would be nice: > 3) Return the parts of the string that matched (in addition to 2 > above, this makes handlind reduced formats more pleasant, rather > than having to infer the week number from a returned DateTime). Return how? > 4) The ability to specify an arbitrary base date for the implied > computations and times I agree with this. But what is there now works well... > I also think you will need 3 to support durations that have the form > of a date (especially since they may not be valid dates if parsed by > DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30 > days). Invalid dates should raise an exception. I'm not sure what to do about the longer then 1 year problem. My thinking is a DT::Duration::Set with multiple durations but the whole thing is fuzzy right now. > Bugs that I have noticed: > a) The parser allows partial extended form on the times, so it takes > 12:3000... But it is matched as 12:30:00. I know about this one - It's because there isn't a forward look ahead in the regex. The fix is coming. > b) It does not allow all combined date and time formats that are > legal (any non-truncated date and any non-reduced time > combination is legal), also the whole expression must be either > entirely in basic or expanded form (not mixed) This is documented in the pod. DF::F::Builder will probably need to be changed. > c) Your fractional_hour does not compute seconds and nanoseconds > (i.e. T10.412342 gives precisely 10:24:00) Hmm... I'm not sure that this is wrong. The spec is kinda vague. > d) Your parse_time only parses the ambiguous time formats, some time > formats are only in parse_datetime This is the same as your point #1. > Other issues (that I didn't solve either): > i) You assume that a minute is 60 seconds in the fractional code > ii) For fractional durations, how do you represent .3 of a month? > (The best answer I could come up with was to use the base date or > today to get the number of days in a month). > Sure, but how much further is it worth bending DT::F::Builder to > handle this finicky standard? A lot. :) This isn't the only weird standard. > > As I've said from the beginning I think your parser is very interesting and I > > don't want to see you abandon it. Perhaps it should be extracted from the ISO8601 > > specific stuff and rolled into a stand alone module for specifying date/time > > formats. Maybe DateTime::Format::Grammar? > > I honestly don't think it is usefull outside of the context of > ISO8601, it has a lot of the odd ISO stuff baked into it and if you > were to do a generic Grammar then DT::F::Builder is a simpler base > (unless you need lots of odd semantics in which case it is probably > better to roll your own). I don't think you could write a Date::Manip replacement in DT::F::Builder yet. Your parser would be pretty good for this. -J _-
