> 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've been using now because I'm not creating parser objects. It simple enough to make it so you can give a DT object to a blessed ISO object. Will that support what you need? > 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. I really don't like extra arguments. I'd rather be able to set the behavior on a per. object basis. > > 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. Except the precision information would be non-standard. I'd rather wait for DT to support this and document that. > > 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. No, I think you misunderstand. :) It is impossible to confuse a duration with a date because of the _P_refix. parse_datetime should (and does) barf on durations. Nor should parse_datetime ever be able to understand durations as then the user wouldn't know the type of the returned object in advance. parse_duration (which doesn't exist yet) should handle these. Theres going to have be another method for parse_everything that the user will have to check the return types from. > > > 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. Do you think it's worth carrying it down to seconds or nanoseconds? I'm open to the idea. I just didn't want to create 'artificial' precision. > > > 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). It's in the Todo to make it so parse_time will parse all times and parse_day will parse all dates. I just want to wait until there are TONS more tests. > > > 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? I don't think there will have to be any special support for ISO8601. Iain has really done a fantastic job with the generalization. -J --
