Many current parsers use DateTime::Format::Strptime as their "real" parser. I'd suggest that we modify strptime to accept an 'incomplete' option that doesn't croak when you don't supply enough parameters but instead returns a DateTime::Incomplete object.

Once that's done, any parser that uses it just needs to be made "incomplete aware". In some cases (ISO8601) being 'incomplete' will depend on the format it's parsing. Eg "2011" is a valid 8601 format. DT:F:ISO8601 would call strptime with { pattern => '%Y', incomplete => 1 }.

This wouldn't be a difficult modification to strptime, and would provide an easy route to ::incomplete for other parsers that already use strptime for parsing.

Cheers!
Rick Measham


On 29/03/2011 9:37 AM, Karen Etheridge wrote:
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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to