I have some sympathy for what you say but it does seem strange to me
that DateTime loses information. I mean, it is supposed to essentially
be a container to hold information about a datetime in a structured
object you can do things with. The problem is that it loses
information about the original data and the information it loses isn't
really very difficult to, well, not lose. A bare year isn't an
"incomplete" datetime really, it's just a low resolution datetime.
Just allowing a couple of almost cosmetic methods to retain the
information about completely unspeficied components (while retaining
the "1" defaults for internal calculations) would fix this and make a
whole slew of new DateTime::Incomplete::Format modules unnecessary.
You say that "you'd still need DateTime::Format::* extended to pass
along information about incompleteness." but these modules already do
since they create DT objects with undef inputs. As far as I can tell,
it's DT which defaults the undefs to "1". All I really want is, for
example:
use DateTime::Format::Natural;
my $parser = DateTime::Format::Natural->new;
my $dt = $parser->parse_datetime('2008');
print "YEAR: ", $dt->year, "\n";
print "MONTH: ", $dt->month, "\n";
print "DAY: ", $dt->day, "\n";
to give:
YEAR: 2008
MONTH:
DAY:
instead of
YEAR: 2008
MONTH: 1
DAY: 1
I don't really care if the methods are new ones so that the current
behaviour remains the same (almost certainly a better thing).
PK
On 24 February 2011 10:40, Zefram <zef...@fysh.org> wrote:
> Philip Kime wrote:
>>Just to clarify further, DateTime::Incomplete isn't any use to me as
>>it doesn't parse dates.
>
> You can't expect a single module to do the whole job. DateTime doesn't
> parse dates either, that's the job of the DateTime::Format::* modules.
> DateTime::Incomplete *is* exactly what you need to represent your partial
> dates; what you're missing is modules to do the parsing, which would
> logically be DateTime::Incomplete::Format::*, which don't exist yet.
>
>> Either the DataTime::Format
>>modules need to have the option of creating DateTime::Incomplete
>>objects instead of DateTime objects (an impossible requirements as
>>there so many DateTime::Format modules) or DateTime needs to provide
>>methods which retain this information
>
> Extending DateTime::Format::* to be able to generate DateTime::Incomplete
> objects would be the other way to do it. Extending DateTime to cover
> DateTime::Incomplete's job, however, would be neither necessary nor
> sufficient: you'd still need DateTime::Format::* extended to pass along
> information about incompleteness.
>
> Unfortunately the parsing modules that you want don't exist yet.
> Your best bet is probably to extend DateTime::Format::* yourself, to
> optionally generate DateTime::Incomplete objects. Then you can negotiate
> about whether your changes should be rolled into the original modules
> or should be released separately as DateTime::Incomplete::Format::*.
>
> -zefram
>
--
Dr Philip Kime
