All good questions. Let me try to clarify:

I need to parse dates and make DateTime objects. Some of my data feeds
don't have a strict date format, some do so I would ideally use
DateTime::Format::Natural and DateTime::Format::ISO8601. The data is
for bibliography typesetting (biblatex ... I develop the 'biber'
backend for this) and so I split the dates out in the day/month/year
components. I don't care about times. I do care whether a date actuall
has a day or month component as I don't want to output "1" if they
don't as this will then go into the bibliography which would be
completely wrong. Since I'm parsing arbitrary bibliography data from
increasingly more disparate data sources, I have no idea about or
control over when there might be conflicts between YYYY and YYYY-01-01
or whatever and I don't want to just say this won't be likely and
leave it at that because the output is bibliography typesetting data
where it really does matter.

I realise that date comparison internally for DateTime is impossible
without defaulting missing components but I don't suggest that any
internals change, just that some methods are available to tell me
whether DateTime object actually dervies from a real or defaulted
month/year otherwise this information is completely lost. Either
DateTime->month/day can return undef if they really were not passed to
the contructor or just two new methods
DateTime->sourcemonth/sourceday or something. My difficulty is that if
you instantiate a DateTime object from some data (using a
DateTime::Format module), you have no way of knowing whether your data
actually had day/month information it it and so there is information
loss.

Just to clarify further, DateTime::Incomplete isn't any use to me as
it doesn't parse dates. You have to pass the components, just like
with DateTime and it's the components I need to get via a module in
the first place (that is, I need to use a DateTime::Format module).

My feeling is that a new DateTime::Format module is not the answer as
these all create DateTime objects anyway. 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

PK

On 24 February 2011 02:04, Metz, Bobby <bobby.m...@globalcrossing.com> wrote:
> 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
>
>



-- 
Dr Philip Kime

Reply via email to