This change is a backport from 10.0 to 5.5 for:
1. The full patch for:
MDEV-4841 Wrong character set of ADDTIME() and DATE_ADD()
9adb6e991e
2. A small fragment of:
MDEV-5298 Illegal mix of collations on timestamp
03f6778d61
which overrides Item_temporal_hybrid_func::cmp_type(),
and adds a new line into cache_temporal_4265.result.
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)
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
Cleanup: remove TIME_FUZZY_DATE.
Introduce TIME_FUZZY_DATES which means "very fuzzy, the resulting
value is only used for comparison. It can be invalid date, fine, as long as it can be
compared".
Updated many tests results (they're better now).
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...
- Reverting the patch for Bug # 12584302
The patch will be reverted in 5.1 and 5.5.
The patch will not be reverted in 5.6, the change will
be properly documented in 5.6.
- Backporting DBUG_ASSERT not to crash on '0000-01-00'
(already fixed in mysql-trunk (5.6))
