Philip,
I'm just trying to understand your problem a bit more, so bear with me.
First, I think the trouble is that you technically can't have a date without a
month and day value, so storing them as undef wouldn't work well, at least not
without sacrificing DateTime math and impacting several modules built around
that expectation. I think this would be especially true for anyone dealing
with timezones.
With that in mind, do you expect the hh:mm:ss values to be undef as
well? The logic of your argument would apply to those values too, but I'm
assuming that you are okay with 00:00:00 since you are looking at dates only,
yes? Further, does your project require that you differentiate between dates
at the day & month level? If no, then why deal with them at all. Just
reformat all of your datetime output values to year value only and call it
quits. If yes, and the undef change is made to DateTime, how would you propose
dealing with DateTime comparisons between vars with undef month/day values to
vars with numeric values?
Assuming undef month/day values won't be supported, how many values
from your data set do you anticipate will have real values of '2008-01-01
00:00:00', therefore producing conflicts with the '2008' => '2008-01-01
00:00:00' conversions done by DateTime? I understand your argument that the
values are incorrect for comparisons, but no more so that an undef value. Your
examples show static values being passed to the new routine. Are you expecting
format variations beyond your examples and therefore relying on DateTime to
recognize multiple formats, thus relieving you of the parsing burden? If you
don't expect format variantion, then I'd argue that parsing values to pass to
DateTime::Incomplete seems like the most straightforward solution, f you have
found that module does everything else you require. I have no familiarity with
it personally and could not advise.
Bobby
> -----Original Message-----
> From: Philip Kime [mailto:phi...@kime.org.uk]
> Sent: Wednesday, February 23, 2011 1:23 PM
> To: datetime@perl.org
> Subject: Re: How to distinguish between no month/day and 01/01?
>
> All I really want is to be able to say:
>
> $dt = DateTime::Format::Somemodule->new('2008');
>
> and have $dt->month and $dt->day return undef instead of "1" otherwise I
> can't distinguish from:
>
> $dt = DateTime::Format::Somemodule->new('2008-01-01');
>
> Even DateTime::Format::ISO8601 doesn't do this even though "2008" is a
> valid ISO8601 date.
>
> PK
>
> On 23 Feb 2011, at 7:54 PM, David Nicol wrote:
>
> > DateTime::Incomplete seems to be about managing ambiguity. It seems to
> > me that what Kime is looking for is a data object with an additional
> > dimension of duration. Time spans are generally stored as two points
> > as exact as the date-time abstraction is use allows, and then there
> > are methods called things like "contains" and "overlaps." An
> > additional dimension is going to be required, if it is a second time
> > point, or an accuracy indicator, or what -- some additional
> > requirements gathering would be needed. After he has rolled his own
> > solution, maybe he will share it?
>
> --
> Dr Philip Kime
