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

From: Date: Wed, 14 May 2003 07:31:33 +0000
Subject: #23611 [Bgs->Opn]: mssql.datetimeconvert should not be on by default
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-39608@lists.php.net to get a copy of this message
 ID:               23611
 User updated by:  janko at dupoint dot com
 Reported By:      janko at dupoint dot com
-Status:           Bogus
+Status:           Open
 Bug Type:         MSSQL related
 Operating System: Windows 2000 Server
 PHP Version:      4.3.1
 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[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



Thread (7 messages)

« previous php.bugs (#39608) next »