You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#30786762: FAILED ASSERTION FOR DATES WITH ZERO OR ABOVE
TIMESTAMP LIMIT
This bug report unfortunately contained two independent
bugs. The first one concerns bounds checking for timestamp
literals and was fixed along with bug no 31239157.
This patch fixes the second bug, failed assertion for
timestamp literals with zero month and a time zone
displacement. We calculate the number of seconds since the
unix epoch in order to adjust time zone diplacement, and the
function doing this, sec_since_epoch64(), asserts that the
month be non-zero.
We fix this by adding a check for zero month, and for
consistency we disallow a day zero as well, for timestamp
literals with a time zone displacement, raising an
error. This check runs independent of sql_mode.
Change-Id: Idfea577c6528afa2d9bd5f30b2c3d8db9525bd8d
Copy file name to clipboardExpand all lines: mysql-test/r/time_zone.result
+22
Original file line number
Diff line number
Diff line change
@@ -588,3 +588,25 @@ a
588
588
1970-01-01 00:00:01.000000
589
589
SET time_zone = DEFAULT;
590
590
DROP TABLE t1, t2;
591
+
#
592
+
# Bug#30786762: FAILED ASSERTION FOR DATES WITH ZERO OR ABOVE TIMESTAMP
593
+
# LIMIT
594
+
#
595
+
SET sql_mode = regexp_replace(@@sql_mode, 'NO_ZERO_IN_DATE', '');
596
+
Warnings:
597
+
Warning 3135 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
0 commit comments