Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL)
-
None
Description
DROP PROCEDURE IF EXISTS p1; |
DELIMITER $$
|
CREATE PROCEDURE p1() |
BEGIN
|
DECLARE ts10 TIMESTAMP(1) DEFAULT NOW(); |
DECLARE ts16 TIMESTAMP(1) DEFAULT NOW(6); |
DECLARE dt10 DATETIME(1) DEFAULT NOW(); |
DECLARE dt16 DATETIME(1) DEFAULT NOW(6); |
|
DECLARE vts10 VARCHAR(32) DEFAULT ts10; |
DECLARE vts16 VARCHAR(32) DEFAULT ts16; |
DECLARE vdt10 VARCHAR(32) DEFAULT dt10; |
DECLARE vdt16 VARCHAR(32) DEFAULT dt16; |
|
SELECT vts10, vts16, vdt10, vdt16; |
END; |
$$
|
DELIMITER ;
|
CALL p1\G
|
vts10: 2018-12-07 16:19:32
|
vts16: 2018-12-07 16:19:32.900000
|
vdt10: 2018-12-07 16:19:32.0
|
vdt16: 2018-12-07 16:19:32.9
|
Notice:
Columns vdt10 and vdt16 returned correct results.
Columns vts10 and vts16 returned wrong results.
- vts10 does not have fractional digits. The expected result is '2018-12-07 16:19:32.0', like it vdt10.
- vts16 has six fractional digits. The expected result is '2018-12-07 16:19:32.9', like it vdt16.
Attachments
Issue Links
- blocks
-
MDEV-13995 MAX(timestamp) returns a wrong result near DST change
- Closed