Skip Menu |
 

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

Report information
The Basics
Id: 7589
Status: resolved
Priority: 0/
Queue: DateTime-Format-MySQL

People
Owner: Nobody in particular
Requestors: tom@eborcom.com (no email address)
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.0301
Fixed in: (no value)



Subject: Parsing undefined TIMESTAMPs fails
Download (untitled) / with headers
text/plain 894b
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.

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:
Download (untitled) / with headers
text/plain 1.1k
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. ===========================*/
From: Tom Hukins
Download (untitled) / with headers
text/plain 991b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.