Description: ------------ Probably due to a PHP bug, it seems that when mssql.datetimeconvert is set to 0. Dates from a MSSQL is converted from 16-08-2007 to 16-07-2007. I assume that PHP takes the last to digits as month - this might be caused by the MSSQL servers timeformat (it's a danish MSSQL server, probably with danish date format). It would be preferrable if the MSSQL connect method didn't automatically set mssql.datetimeconvert to 0 or at least if the option could be given through the DSN string to avoid this behavior. Test script: --------------- <?php $dsn = 'mssql://user:pass@host:1433/db' $options = array( 'debug' => 2, 'portability' => MDB2_PORTABILITY_ALL, ); $conn =& MDB2::connect($dsn, $options); $res = $conn->query("select date_field from date_table"); $row = $res->fetchRow(); echo $row["date_field"]; ?> Expected result: ---------------- I expected the script to output 2007-08-16 Actual result: -------------- The script output 2007-07-16

I'll have a look at this, adding an option could be possible I think.

I had the same problem with MSSQL Driver v1.2.1 and newest (as of today) FreeTDS. Recompiling PHP helped - more info at http://blog.kotowicz.net/2009/09/weird-date-format-from-freetds-with.html

I just noticed from the code (Driver/mssql.php) these three lines: if ((bool)ini_get('mssql.datetimeconvert')) { @ini_set('mssql.datetimeconvert', '0'); } This seems quite bogus to me but I'm investigating to see if there's a reason for that before I do anything.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Ok here's what I did, I added the ability to have a new option in your factory. So when you are invoking MDB2:factory you can pass $options as the second argument. In this case make sure to have the key / value pair 'datetimeconvert' => 1 or 'datetimeconvert' => true This has to be documented but the bug itself is resolved for now.