Skip Menu |

This queue is for tickets about the DateTime-Format-Natural CPAN distribution.

Report information
The Basics
Id: 83233
Status: resolved
Priority: 0/
Queue: DateTime-Format-Natural

People
Owner: Nobody in particular
Requestors: CDRAKE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 1.01_04
Fixed in: (no value)



Subject: Silently returns wrong day
I feed it "last week", it returns "today". That's BAD! # perl -e 'use DateTime::Format::Natural; $parser = DateTime::Format::Natural->new; print $parser->parse_datetime("Sun, 3 Feb 2013 07:34:34 GMT");' 2013-02-09T03:37:24
Subject: Re: [rt.cpan.org #83233] Silently returns wrong day
Date: Sat, 9 Feb 2013 14:25:17 +0100
To: CDRAKE via RT <bug-DateTime-Format-Natural [...] rt.cpan.org>
From: Steven Schubiger <schubiger [...] cpan.org>
CDRAKE via RT <bug-DateTime-Format-Natural@rt.cpan.org> wrote: Show quoted text
> I feed it "last week", it returns "today". That's BAD! > > # perl -e 'use DateTime::Format::Natural; $parser = > DateTime::Format::Natural->new; print $parser->parse_datetime("Sun, 3 Feb > 2013 07:34:34 GMT");' > > 2013-02-09T03:37:24
This is documented under BUGS & CAVEATS: C<parse_datetime()>/C<parse_datetime_duration()> always return one or two DateTime objects regardless whether the parse was successful or not. In case no valid expression was found or a failure occurred, an unaltered DateTime object with its initial values (most often the "current" now) is likely to be returned. It is therefore recommended to use C<success()> to assert that the parse did succeed (at least, for common uses), otherwise the absence of a parse failure cannot be guaranteed.