On Sat, Jul 05, 2003 at 06:56:32PM -1000, Joshua Hoblitt wrote:
> I want to preserve the revision history of my tree so the move to SF won't be until
> next week.
Ok.
> What really needs to be done is a lot more tests. I'm considering a framework for
> building tests.
Ok, I can try to port over my framework when your code is checked in,
although it relies on being able to pass in a base date and be able to
select the return classes so I am not sure how easy it is to do.
> > 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.
What is your proposed API? From the discussion on the DT list Dave
preferred extra arguments to parse_datetime which is what I ended up
implementing.
> > 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.
Yes, but you don't need them. In the interface discussion Dave said
using wantarray() and returning extra fields was fine.
> > 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?
My module had the return signature
($datetime_object, $format_info, $parsed_parts) = parse_datetime( ... )
> > 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 disagree. When I am dealing with a time I need to be able to say
what date is implied.
> > 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.
No, I think you misunderstand. They are not invalid dates because
they are not dates. The duration format has 2 valid syntaxes, one is
the explicit P2Y2M30DT4H5M6S syntax, the other specifies them as if
they were dates, so the above period can also be P00020230T040506
which is a valid duration, but an invalid date if you use your date
parser to parse it rather than duplicate the formats.
> > 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.
Fair enough.
> > 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.
I don't think so. All I am saying here is that some time formats are
only parsable with parse_datetime and others with parse_time. I would
have expected all time formats to be parseable with parse time and not
with parse_datetime (unless perhaps they had a leading T).
> > 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.
No, my point is how far should it bend specifically for this 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.
I agree with the first point, but I am not sure about the second.
-ben
