On Tue, 22 Jul 2003, Joshua Hoblitt wrote: > > For example, the set() method will attempt to unconditionally call set() > > on the base object. But if the base is 2003-02-10T00:00:00 and one calls > > "$dti->set( day => 30 )" then we'll get a validation error. But if the > > incomplete object only has a known year, there's no reason to error out > > (yet). And the docs say you can do "set( day => undef )" but that will > > clearly break badly. > > It might be better to just use utc_rd_values() and have one object. > DT::Calendar::Incomplete might be a good name too.
?? We can't know utc_rd_values for incomplete datetimes. What is the utc_rd_value of "July 22"? > > So clearly this needs fixing. I'm also not too keen on the way it stores > > the datetime data in both the incomplete object and the base object. It > > should all be in one spot, ideally, otherwise we'd end having > > to re-implement things like "quarter" and "day_of_week" and so on. > > My original vision was to just make this a subclass/decorator of DT with > some attributes tacked on. I'm not sure how practical that would have > been. At least we're learning something from the current > implementation. The current implementation is sort of half-a-decorator. I started reworking it to be a real decorator, and then got stuck on the "day 30 for February base" problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
