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, [email protected] GCS C+++$ USL+++$ P+++$ w--- M++
