Bug #7589 for DateTime-Format-MySQL: Parsing undefined TIMESTAMPs fails

Thu Sep 09 05:18:38 2004 Guest - Ticket created

Subject:

Parsing undefined TIMESTAMPs fails

Using MySQL 4.1 and DateTime::Format::MySQL causes parse_datetime to fail when processing undefined TIMESTAMP fields. The attached script reproduces this error. The error returned is: The 'month' parameter ("00") to DateTime::new did not pass the 'is between 1 and 12' callback at /usr/local/lib/perl5/site_perl/5.8.5/DateTime/Format/Builder/Parser/Regex.pm line 135 After running this script, the database contains something like: +---------------------+---------------------+ | first | second | +---------------------+---------------------+ | 2004-09-09 10:12:54 | 0000-00-00 00:00:00 | +---------------------+---------------------+ The problem occurs because DateTime does not recognise the zeros in the 'second' field as a valid date. This occurs on FreeBSD-5.2.1 with Perl 5.8.5 and MySQL 4.1.3-beta. Let me know if you need more information. Thanks, Tom

Download fail
application/octet-stream 597b

Message body not shown because it is not plain text.

Thu Sep 09 09:32:40 2004 autarch [...] urth.org - Correspondence added

Date:	Thu, 9 Sep 2004 08:09:50 -0500 (CDT)
From:	Dave Rolsky <autarch [...] urth.org>
To:	Guest via RT <bug-DateTime-Format-MySQL [...] rt.cpan.org>
Subject:	Re: [cpan #7589] Parsing undefined TIMESTAMPs fails
RT-Send-Cc:

On Thu, 9 Sep 2004, Guest via RT wrote: Show quoted text

> This message about DateTime-Format-MySQL was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=7589 > > > Using MySQL 4.1 and DateTime::Format::MySQL causes parse_datetime to fail when processing undefined TIMESTAMP fields. The attached script reproduces this error. > > The error returned is: > The 'month' parameter ("00") to DateTime::new did not pass the 'is between 1 and 12' callback > at /usr/local/lib/perl5/site_perl/5.8.5/DateTime/Format/Builder/Parser/Regex.pm line 135 > > After running this script, the database contains something like: > +---------------------+---------------------+ > | first | second | > +---------------------+---------------------+ > | 2004-09-09 10:12:54 | 0000-00-00 00:00:00 | > +---------------------+---------------------+ > > The problem occurs because DateTime does not recognise the zeros in the 'second' field as a valid date.

It's not a valid date. How is this a bug? -dave /*=========================== VegGuide.Org Your guide to all that's veg. ===========================*/

Fri Sep 10 04:55:13 2004 Guest - Correspondence added

From:

Tom Hukins

I replied to this by mail, but it seems I sent a comment which hasn't been recorded in public. [autarch@urth.org - Thu Sep 9 09:32:40 2004]: Show quoted text

> It's not a valid date. How is this a bug?

Here's my reasoning: If I set one column on a record, but don't define another (as per my example), I expect the unset value to be ignored. If both these fields were CHAR, the unset value defaults to NULL. NULL isn't a CHAR, an INT or any other data type that one might set a column to. If I have an unset TIMESTAMP or DATETIME (for example, an unknown birthday) I assume similar behaviour. MySQL represents such fields with its zero value. So, I can't easily use DateTime::Format::MySQL if I have any undefined dates/times. I could check for something like m/[1-9]/ on timestamps before passing them to parse_datetime(), but jumping through this extra hoop doesn't appeal. I appreciate the point that parsing invalid timestamps isn't strictly a bug, but for me, at least, it's an inconvenience.

Mon Jan 03 01:21:11 2005 DROLSKY [...] cpan.org - Status changed from 'new' to 'resolved'