Added test cases for Datetime conversion tests

Author: arvis108

tests/test_004_cursor.py

@@ -6909,145 +6909,89 @@ def test_money_smallmoney_invalid_values(cursor, db_connection):
         drop_table_if_exists(cursor, "dbo.money_test")
         db_connection.commit()
 
-def test_string_vs_datetime_parameter_behavior(cursor, db_connection):
-    """
-    Test the difference between using string parameters vs datetime object parameters.
-    
-    This test demonstrates that:
-    1. String parameters like '2025-08-12' are treated as literal strings
-    2. Datetime objects like date(2025, 8, 12) are properly handled as datetime types
-    3. Both approaches work correctly in their intended contexts
-    """
-    try:
-        # Create test table with both string and date columns
-        drop_table_if_exists(cursor, "#pytest_string_vs_datetime")
-        cursor.execute("""
-            CREATE TABLE #pytest_string_vs_datetime (
-                id INT PRIMARY KEY,
-                string_col NVARCHAR(50),
-                date_col DATE
+def test_date_string_parameter_binding(cursor, db_connection):
+    """Verify that date-like strings are treated as strings in parameter binding"""
+    table_name = "#pytest_date_string"
+    try:
+        drop_table_if_exists(cursor, table_name)
+        cursor.execute(f"""
+            CREATE TABLE {table_name} (
+                a_column VARCHAR(20)
             )
         """)
+        cursor.execute(f"INSERT INTO {table_name} (a_column) VALUES ('string1'), ('string2')")
         db_connection.commit()
-        
-        # Test 1: Insert using actual datetime objects (should work)
-        actual_date = date(2025, 8, 12)
-        cursor.execute("INSERT INTO #pytest_string_vs_datetime (id, string_col, date_col) VALUES (?, ?, ?)", 
-                      (1, "test_string", actual_date))
-        db_connection.commit()
-        
-        # Test 2: Insert string into string column (should work)
-        date_string = '2025-08-12'
-        cursor.execute("INSERT INTO #pytest_string_vs_datetime (id, string_col, date_col) VALUES (?, ?, ?)", 
-                      (2, date_string, actual_date))
-        db_connection.commit()
-        
-        # Test 3: Query using string parameter (should work as string comparison)
-        cursor.execute("SELECT id FROM #pytest_string_vs_datetime WHERE string_col = ?", (date_string,))
-        rows = cursor.fetchall()
-        assert len(rows) == 1, f"Expected 1 row for string comparison, got {len(rows)}"
-        assert rows[0][0] == 2, "Should find row 2 with matching string"
-        
-        # Test 4: Query using datetime object parameter (should work as date comparison)
-        cursor.execute("SELECT id FROM #pytest_string_vs_datetime WHERE date_col = ?", (actual_date,))
-        rows = cursor.fetchall()
-        assert len(rows) == 2, f"Expected 2 rows for date comparison, got {len(rows)}"
-        
-        # Test 5: Verify string functions work with string parameters (the original bug)
-        cursor.execute("SELECT id FROM #pytest_string_vs_datetime WHERE RIGHT(string_col, 10) = ?", (date_string,))
+
+        date_str = "2025-08-12"
+
+        # Should fail to match anything, since binding may treat it as DATE not VARCHAR
+        cursor.execute(f"SELECT a_column FROM {table_name} WHERE RIGHT(a_column, 10) = ?", (date_str,))
         rows = cursor.fetchall()
-        assert len(rows) == 1, f"RIGHT() function should work with string parameter, got {len(rows)} rows"
-        
+
+        assert rows == [], f"Expected no match for date-like string, got {rows}"
+
     except Exception as e:
-        pytest.fail(f"String vs datetime parameter behavior test failed: {e}")
+        pytest.fail(f"Date string parameter binding test failed: {e}")
     finally:
-        drop_table_if_exists(cursor, "#pytest_string_vs_datetime")
+        drop_table_if_exists(cursor, table_name)
         db_connection.commit()
 
-def test_string_parameters_no_conversion_error(cursor, db_connection):
-    """
-    Test that string parameters that look like dates do NOT get automatically converted.
-    
-    This reproduces the exact scenario from the original bug report.
-    """
+
+def test_time_string_parameter_binding(cursor, db_connection):
+    """Verify that time-like strings are treated as strings in parameter binding"""
+    table_name = "#pytest_time_string"
     try:
-        # Create table similar to original bug report
-        drop_table_if_exists(cursor, "#pytest_string_no_conversion")
-        cursor.execute("CREATE TABLE #pytest_string_no_conversion (id INT, IncFileName NVARCHAR(100))")
-        db_connection.commit()
-        
-        # Insert test data
-        cursor.execute("INSERT INTO #pytest_string_no_conversion VALUES (1, 'order_data_2025-08-12')")
-        cursor.execute("INSERT INTO #pytest_string_no_conversion VALUES (2, 'order_data_2025-08-13')")
+        drop_table_if_exists(cursor, table_name)
+        cursor.execute(f"""
+            CREATE TABLE {table_name} (
+                time_col VARCHAR(22)
+            )
+        """)
+        cursor.execute(f"INSERT INTO {table_name} (time_col) VALUES ('prefix_14:30:45_suffix')")
         db_connection.commit()
-        
-        # The exact failing case from the bug report - should now work
-        date_str = '2025-08-12'
-        cursor.execute("SELECT IncFileName FROM #pytest_string_no_conversion WHERE RIGHT(IncFileName,10) = ?", 
-                      (str(date_str),))
+
+        time_str = "14:30:45"
+
+        # This should fail because '14:30:45' gets converted to TIME type
+        # and SQL Server can't compare TIME against VARCHAR with prefix/suffix
+        cursor.execute(f"SELECT time_col FROM {table_name} WHERE time_col = ?", (time_str,))
         rows = cursor.fetchall()
-        
-        # Should find exactly one match
-        assert len(rows) == 1, f"Expected 1 matching row, got {len(rows)}"
-        assert rows[0][0] == "order_data_2025-08-12", "Should find the correct filename"
-        
+
+        assert rows == [], f"Expected no match for time-like string, got {rows}"
+
     except Exception as e:
-        pytest.fail(f"String parameter no conversion error test failed: {e}")
+        pytest.fail(f"Time string parameter binding test failed: {e}")
     finally:
-        drop_table_if_exists(cursor, "#pytest_string_no_conversion")
+        drop_table_if_exists(cursor, table_name)
         db_connection.commit()
 
-def test_datetime_objects_still_work(cursor, db_connection):
-    """
-    Test that actual datetime objects still work correctly after our fix.
-    
-    This ensures backward compatibility - existing code using datetime objects
-    should continue to work exactly as before.
-    """
+
+def test_datetime_string_parameter_binding(cursor, db_connection):
+    """Verify that datetime-like strings are treated as strings in parameter binding"""
+    table_name = "#pytest_datetime_string"
     try:
-        # Create table with various datetime column types
-        drop_table_if_exists(cursor, "#pytest_datetime_still_works")
-        cursor.execute("""
-            CREATE TABLE #pytest_datetime_still_works (
-                id INT PRIMARY KEY,
-                date_col DATE,
-                datetime_col DATETIME,
-                time_col TIME
+        drop_table_if_exists(cursor, table_name)
+        cursor.execute(f"""
+            CREATE TABLE {table_name} (
+                datetime_col VARCHAR(33)
             )
         """)
+        cursor.execute(f"INSERT INTO {table_name} (datetime_col) VALUES ('prefix_2025-08-12T14:30:45_suffix')")
         db_connection.commit()
-        
-        # Test with actual datetime objects (should work as before)
-        test_date = date(2025, 8, 12)
-        test_datetime = datetime(2025, 8, 12, 14, 30, 0)
-        test_time = time(14, 30, 0)
-        
-        # INSERT using datetime objects
-        cursor.execute("""
-            INSERT INTO #pytest_datetime_still_works 
-            (id, date_col, datetime_col, time_col) 
-            VALUES (?, ?, ?, ?)
-        """, (1, test_date, test_datetime, test_time))
-        db_connection.commit()
-        
-        # SELECT using datetime objects as parameters
-        cursor.execute("SELECT id FROM #pytest_datetime_still_works WHERE date_col = ?", (test_date,))
-        rows = cursor.fetchall()
-        assert len(rows) == 1, f"Datetime object parameter should work, got {len(rows)} rows"
-        
-        cursor.execute("SELECT id FROM #pytest_datetime_still_works WHERE time_col = ?", (test_time,))
+
+        datetime_str = "2025-08-12T14:30:45"
+
+        # This should fail because '2025-08-12T14:30:45' gets converted to TIMESTAMP type
+        # and SQL Server can't compare TIMESTAMP against VARCHAR with prefix/suffix
+        cursor.execute(f"SELECT datetime_col FROM {table_name} WHERE datetime_col = ?", (datetime_str,))
         rows = cursor.fetchall()
-        assert len(rows) == 1, f"Time object parameter should work, got {len(rows)} rows"
-        
-        # Verify the data was stored correctly
-        cursor.execute("SELECT date_col, datetime_col, time_col FROM #pytest_datetime_still_works WHERE id = 1")
-        row = cursor.fetchone()
-        assert row is not None, "Should retrieve the inserted datetime data"
-        
+
+        assert rows == [], f"Expected no match for datetime-like string, got {rows}"
+
     except Exception as e:
-        pytest.fail(f"Datetime objects still work test failed: {e}")
+        pytest.fail(f"Datetime string parameter binding test failed: {e}")
     finally:
-        drop_table_if_exists(cursor, "#pytest_datetime_still_works")
+        drop_table_if_exists(cursor, table_name)
         db_connection.commit()
 
 def test_close(db_connection):