I just started using DateTime::Incomplete for a project and discovered that would be handy to have a string parser, so I came back and re-read this thread :)
Regarding the message quoted below, my assessment is that all that is needed to be written (from scratch) is a DateTime::Format::Incomplete::Builder module -- then the various DateTime::Format::YourType modules can be mostly recycled into passing their parsers into this new modules. Alternatively, it might be possible to change the DateTime::Format::* family into constructing other object types (than vanilla DateTime), but that sounds like a refactoring pass to follow the initial version as I described above. On Wed, Feb 23, 2011 at 06:47:37PM +0100, Philip Kime wrote: > Greetings, > I can't seem to find a DateTime::Format module which will leave day/month > undef if I pass just a year like "2008". When parsing bibliographies, it's > important to be able to distinguish between, say > > 2008 > 2008-01 > 2008-01-01 > > Every module I've found sets the day or month to "1" if it's not in the input > which makes it impossible to tell if there really is a day/month in the input > without parsing the input (which makes using a DateTime::Format module > pointless ...). Is there a way to do this? I know about DateTime::Incomplete > but that doesn't parse dates, you have to have already split the date up to > pass to it ... > It seems that all of the DateTime::Format::* modules parse into DateTime > objects which always default day/month to "1". > > PK > -- > Dr Philip Kime -- "Martyrdom has always been a proof of the intensity, never of the correctness, of a belief." - Arthur Schnitzler . . . . . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++