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++

Reply via email to