Short answer: no. If you want to use DateTime then I'd recommend the DateTime::Format::DBI module or something like it:
http://search.cpan.org/~cfaerber/DateTime-Format-DBI-0.031/lib/DateTime/Format/DBI.pm Tim. On Mon, Jan 19, 2004 at 10:15:05AM -0500, John Siracusa wrote: > On 1/18/04 6:33 PM, Tim Bunce wrote: > > My preference is that after doing: > > > > $sth->bind_column(1, undef, SQL_DATE); > > $sth->bind_column(2, undef, SQL_DATETIME); > > $sth->bind_column(3, undef, SQL_TIMESTAMP); > > > > the driver should ensure that it returns values for those three column in the > > corresponding international standard formats (as per ODBC). > > > > Similarly, when doing: > > > > $sth->bind_param(1, $foo, SQL_DATE); > > $sth->bind_param(2, $bar, SQL_DATETIME); > > $sth->bind_param(3, $baz, SQL_TIMESTAMP); > > > > the driver should expect to find the values given to it already in > > the correct standard format for the specified type. The driver can then > > convert if it needs to, but few will as the standard format is recognized > > by almost all db's. > > > > Beyond that I'd like to add a way to have a callback fired when a > > value is fetched. Something like: > > > > $sth->bind_column(1, undef, { OnFetch => $code_ref }); > > > > and then you could do whatever you wanted. (I don't see a significant > > need for a corresponding hook for bind_param and/or execute.) > > These are all good suggestions, but to implement them you'll need an API > similar to the one I described. Sure, it could be internal or non-standard, > but that'd miss the point of my proposal. Not all parsing/formatting can be > conveniently done at "bind columns" time. Indeed, not every DBI use case > even calls for binding columns. Whether or not what you described is > implemented, I think we still need a user-visible API like the one I > described that can be use outside of bind_columns() on any data at any time, > so long as there's a $dbh available. > > >> Taken to the next level (a la Perl 6 and Larry-think :) DBI 2 could > >> implement all of this as part of a generic DBD-specific column type > >> formatting/parsing system. But I just care about dates right now :) > > > > I don't think a column type formatting/parsing system is needed. > > But I do thing a "column type system" is needed to provide the hooks > > that'll enable you to do what you want. It needs more thinking > > though and, once the DBI takes over setting each fetched field values, > > it can be added in without drivers having to change at all. > > Having DBI twiddle fetched values for me is useful, but I'd also like the > lower-overhead option of doing it myself only when I need to via explicit > calls to parse_*() and format_*()functions. I'd also much rather deal with > DateTime objects as the interchange format, not ISO date strings, especially > when date math and comparisons are called for. > > DateTime objects are heavyweight too, so maybe ISO dates could be used as > the interchange format in the bind-columns-driven DBD-independent system > that you describe, but then I'd like a DBD-specific parsing/formatting API > to be built on top of that :) That's something each DBD author would have > to add, but a common "internal" interchange format (ISO dates) might make > that easier. The DBDs would also have to implement the keyword parsing, > pass-through, and translation. > > -John >
