UNIX_TIMESTAMP(STR_TO_DATE('201506', "%Y%M"
Issue:
-----
When an invalid date is supplied to the UNIX_TIMESTAMP
function from STR_TO_DATE, no check is performed before
converting it to a timestamp value.
SOLUTION:
---------
Add the check_date function and only if it succeeds,
proceed to the timestamp conversion.
No warning will be returned for dates having zero in
month/date, since partial dates are allowed. UNIX_TIMESTAMP
will return only a zero for such values.
The problem has been handled in 5.6+ with WL#946.
MDEV-6099 Bad results for DATE_ADD(.., INTERVAL 2000000000000000000.0 SECOND)
MDEV-6097 Inconsistent results for CAST(int,decimal,double AS DATETIME)
MDEV-6100 No warning on CAST(9000000 AS TIME)
A huge number in the "day" part of an interval made the code to return
a negative date erroneously. Adding a test to return an error on a too
large "day" value.
The crash happened because Item_func_monthname was derived from
Item_func_month, so Item_func_monthname::is_null() did not work fine.
Backporting a change from 5.5: Item_func_monthname is now derived from
Item_str_func.
Adding test cases from the bug report only.
The problem was earlier fixed by:
MDEV-4863 COALESCE(time_or_datetime) returns wrong results in numeric context
modified:
mysql-test/r/func_time.result
mysql-test/t/func_time.test
Adding a test case only.
The problem was fixed by:
MDEV-4724 Some temporal functions do not preserve microseconds
modified:
mysql-test/r/func_time.result
mysql-test/t/func_time.test
Also, fixing a bug in STR_TO_DATE(). It erroneously returned
error in strict mode for dates like '0000-01-01'
(zero year, but non-zero month and day).
According to the manual:
- NO_ZERO_DATE disallows 0000-00-00 (all date parts are zeros)
- NO_ZERO_IN_DATE disallows zero month (YYYY-00-DD) or day (YYYY-MM-00).
0000-01-01 is a valid date, even in strict mode.
modified:
mysql-test/r/func_time.result
mysql-test/r/strict.result
mysql-test/t/func_time.test
mysql-test/t/strict.test
sql/item_timefunc.cc
sql/sql_time.h
pending merges:
Alexander Barkov 2013-06-17 MDEV-4635 Crash in UNIX_TIMESTAMP(STR_TO_DAT...
Change Item_func_get_system_var::val_xxx functions to use that.
mysql-test/t/variables.test:
@@GLOBAL.INIT_CONNECT is never NULL anymore. Nor it ever was.
It was a bug that empty string system variables appeared as NULL
in the *integer context* (but not in a string, real, or decimal context!)
