#23611 [Opn]: mssql.datetimeconvert should not be on by default

ID: 23611 Updated by: fmk@php.net Reported By: janko at dupoint dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows 2000 Server PHP Version: 4.3.1 New Comment: Testing without PEAR does not give me any errors. This is my code <?php dl("php_mssql.dll"); $con = mssql_connect("local", "user", "pass"); $result=mssql_query("SELECT {fn NOW()}"); $row = mssql_fetch_row($result); print_r($row); $date = $row[0]; $result1=mssql_query("SELECT CAST('$date' AS DATETIME)"); $row1 = mssql_fetch_row($result1); print_r($row1); ?> and the output Array ( [0] => May 14 2003 5:15PM ) Array ( [0] => May 14 2003 5:15PM ) I would say this is a server configuration problem. specific to your local settings. Wow did you create the alias (Client Network Utility) and what is the value of the different options you can configure ? Previous Comments: ------------------------------------------------------------------------ [2003-05-14 02:31:32] janko at dupoint dot com The default behavior also breaks a lot of code, I dare say including PEAR. Consider the following example: <?php require_once "DB.php"; $db = DB::connect("mssql://user:pass@localhost/db"); $sql = "SELECT {fn NOW()}"; $date = $db->getOne($sql); echo "NOW() is $date<br />"; $sql = "SELECT CAST('$date' AS DATETIME)"; $date = $db->getOne($sql); if (DB::isError($date)) { echo $date->toString(); } else { echo "The date is $date"; } ?> Now, the only reasonable outcome of this code would be to print the same date twice, regardless of which format it was initially... right? Well, no. Here's what I get from running this code: NOW() is 14 maj 2003 9:03 [db_error: message="DB Error: " code=-1 mode=return level=notice prefix="" info="SELECT CAST('14 maj 2003 9:03' AS DATETIME) [nativecode=Syntax error converting datetime from character string.]"] Switch the SELECT CAST() for an INSERT statement and you'll realize why this is dangerous. It works for ten months of the year, and breaks in May (maj) and October (oktober). Different host languages will cause the code to work or fail in different months. Yes, I realize that changing this behaviour would also affect a lot of existing code. But this would mostly be a cosmetical change, unless the existing code is completely dependent on parsing the date as a string. But as I can tell you first-hand, trying to explain to a customer why their code suddenly stopped working by the turn of May without us changing anything is _not_ my idea of fun. ------------------------------------------------------------------------ [2003-05-13 14:03:29] fmk@php.net Before this ini parameter was introduced the default behavior of the extension was to convvert the dates. If we changed this we would break a lot of code. ------------------------------------------------------------------------ [2003-05-13 10:22:14] janko at dupoint dot com One thing that puzzled me and my co-workers for the longest of time is that MSSQL flat out refused to return dates in any sensible form, but insisted on returning them 'formatted' - in Swedish (the server's locale). Now, on certain months (Januari - jan; februari - feb) this would at least work, although we lost precision as it would only return minutes, not seconds. On other months (Maj - maj, Oktober - okt), we suddenly couldn't enter into the database what it had given us, because it didn't understand what it seemingly just gave us. We were just about to go through a major overhaul of our application due to this problem, which would have cost us insane amounts of time and money, when we almost accidentally stumbled over the ini setting mssql.datetimeconvert. Turn it off, and hey - over a year of frustration ends. I think it goes without saying that this ini variable should _not_ be turned on in a default installation. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23611&edit=1