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