Hi,
I am not a member of this mailing list, but I have an idea about the
development of DBI.
I have written a date module for perl, called Class::Date. I think
DBI users can give transparent date handling with DBI and
Class::Date, but I need some support from the developers of DBI.
Class::Date is a date object for perl, and I want to give the
possibility to the DBI users to use these modules as bind parameters
for perl types, and I don't want the users care about what date
format a database requires.
Class::Date has a global variable, called $Class::Date::DATE_FORMAT,
which can localized in the "bind" and "execute" DBI methods, and the
resulting SQL query will contain a well-stringified date.
I want to demonstrate this feature:
use Class::Date qw(date); # "date" creates a Class::Date object
$x = date("2001-11-13 15:32");
print "$x\n";
2001-11-13 15:32:00
$Class::Date::DATE_FORMAT="%s";
print "$x\n";
1005661920
$Class::Date::DATE_FORMAT="%a, %d %b %Y %H:%M:%S %z";
print "$x\n";
Tue, 13 Nov 2001 15:32:00 +0200
I would like the DBI development team to support this date as part
of the DBI API, e.g. DBD writers could provide the DATE_FORMAT
string to the DBI functions, and when necessary, localize the
Class::Date::DATE_FORMAT. It costs nothing, but one line in two
function, and does not require Class::Date (no problem if the user
does not even have it).
With this solution, DBI can extend the database-independency more,
the user does not have to convert his dates to the proper format,
the DBD::* modules will know what format the specific database
requires, and will convert the date to that format.
How about that?
Regards,
dLux
--
:wq
