On Fri, Jul 04, 2003 at 09:11:22AM -1000, Joshua Hoblitt wrote:
> I'm planning on moving my tree to SF CVS as soon as I return from OSCON. Then we
> can merge as much as we can from your tree into mine.
I assume you have a personal CVS repository? Otherwise you can just
cvs add it over...
> A new version was sent to CPAN last night. A road-map was sent to the list along
> with the release. Basically the next release will be bug fixes and more tests -
> hopefully a thousand or more new tests. Then the ISO section 5.5 stuff can be
> started on. I'm planning on working with Iain and Flavio for any changes needed to
> DT::F::Builder or DT::Duration::Set (when it's written).
Sorry, I skipped over that message. I dug it up and read it.
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
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.
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).
4) The ability to specify an arbitrary base date for the implied
computations and times
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).
Bugs that I have noticed:
a) The parser allows partial extended form on the times, so it takes
12:3000...
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)
c) Your fractional_hour does not compute seconds and nanoseconds
(i.e. T10.412342 gives precisely 10:24:00)
d) Your parse_time only parses the ambiguous time formats, some time
formats are only in parse_datetime
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).
> By collaborating with Iain while working on my ISO parser many very useful features
> have been incorporated into DT::F::Builder. I'd like to continue along this path as
> it has potential benefits for other authors. Of course your help is welcomed.
Sure, but how much further is it worth bending DT::F::Builder to
handle this finicky 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).
-ben
