Description:
When a numeric LHS cannot be converted to DATETIME and BETWEEN is evaluated via the compare_as_datetimes_with_strings path, the raised error names the perfectly valid constant instead of the operand that actually failed to convert:
SET sql_mode='';
SELECT 1e300 BETWEEN TIMESTAMP'2024-01-01' AND TIMESTAMP'2030-01-01'];
-- ERROR 1525 (HY000): Incorrect DATETIME value: '2024-01-01'
'2024-01-01' is a fully valid literal; the actual failure is the conversion of 1e300 (LHS) to DATETIME. A user following the message would inspect the constant instead of the LHS expression/column.
Additionally the error is raised even with sql_mode='' (non-strict), while the TIME-bounds variant of the same query shape is silent (see companion report BUG-M1), so error behavior is also inconsistent across temporal types.
How to repeat:
SET sql_mode='';
SELECT 1e300 BETWEEN TIMESTAMP'2024-01-01' AND TIMESTAMP'2030-01-01'];
-- ERROR 1525 (HY000): Incorrect DATETIME value: '2024-01-01' <-- blames the constant
SELECT 'abc' BETWEEN DATE'2024-01-01' AND DATE'2030-01-01'];
-- ERROR 1525 (HY000): Incorrect DATE value: 'abc' <-- raised in non-strict mode
SELECT 'abc' BETWEEN TIME'00:00:00' AND TIME'23:59:59';
-- no error (silent 0) <-- inconsistent
Suggested fix:
In the error-reporting path of Item_func_between::val_int() / Arg_comparator temporal handling, reference the operand whose conversion failed (args[0], the LHS) rather than the constant bound. Align strict/non- strict behavior with the rest of the temporal comparison paths (non-strict should degrade to warning + NULL).
