Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Duplicate
-
10.11, 11.4, 11.8, 12.3, 13.1, 12.3.3
-
Linux x86_64, MariaDB.org Ubuntu 24.04 binary distribution
-
Not for Release Notes
Description
Casting an exact numeric value whose fractional component is 999999 to TIME(6) returns NULL, although the same value supplied as text converts successfully. This was reproduced on MariaDB 12.3.3.
This occurs when an exact numeric value at the maximum six-digit fractional TIME boundary is converted to TIME(6).
Boundary test
Save the following as test.sql. The decimal literals are exact; this test does not involve floating-point approximation.
SELECT 'positive_boundary' AS case_name, |
CAST(0.999999 AS TIME(6)) AS numeric_time, |
CAST('0.999999' AS TIME(6)) AS string_time, |
CAST(0.999999 AS TIME(6)) <=> CAST('0.999999' AS TIME(6)) AS equivalent; |
SHOW WARNINGS;
|
SELECT 'lower_neighbor' AS case_name, |
CAST(0.999998 AS TIME(6)) AS numeric_time, |
CAST('0.999998' AS TIME(6)) AS string_time, |
CAST(0.999998 AS TIME(6)) <=> CAST('0.999998' AS TIME(6)) AS equivalent; |
SELECT 'negative_boundary' AS case_name, |
CAST(-0.999999 AS TIME(6)) AS numeric_time, |
CAST('-0.999999' AS TIME(6)) AS string_time, |
CAST(-0.999999 AS TIME(6)) <=> CAST('-0.999999' AS TIME(6)) AS equivalent; |
SELECT 'nonzero_seconds' AS case_name, |
CAST(12.999999 AS TIME(6)) AS numeric_time, |
CAST('12.999999' AS TIME(6)) AS string_time, |
CAST(12.999999 AS TIME(6)) <=> CAST('12.999999' AS TIME(6)) AS equivalent; |
Run it with:
mariadb < test.sql |
Decisive observation
The recorded execution returned:
positive_boundary NULL 00:00:00.999999 0
|
Warning 1292 Incorrect time value: '0.999999'
|
Warning 1292 Truncated incorrect time value: '0.999999'
|
lower_neighbor 00:00:00.999998 00:00:00.999998 1
|
negative_boundary NULL -00:00:00.999999 0
|
nonzero_seconds NULL 00:00:12.999999 0
|
The .999998 neighbor succeeds through both conversion paths, while the valid .999999 endpoint fails only for exact numeric input. The numeric and textual forms should remain non-NULL and equal at this boundary: 00:00:00.999999, -00:00:00.999999, and 00:00:12.999999 respectively.
Source-supported mechanism
The supplied source defines TIME_MAX_SECOND_PART as 999999, and general temporal range validation rejects only values greater than that maximum. The numeric TIME conversion path instead checks sec_part >= TIME_MAX_SECOND_PART, so it rejects the inclusive endpoint itself. Changing that comparison to preserve the inclusive maximum is consistent with both the demonstrated neighbor control and the declared range.
Attachments
Issue Links
- duplicates
-
MDEV-39646 Logic bug: Numeric TIME(6) cast rejects 0.999999
-
- Confirmed
-