github-actions[bot] commented on code in PR #67500:
URL: https://github.com/apache/doris/pull/67500#discussion_r3926208664


##########
be/src/core/value/time_value.h:
##########
@@ -43,7 +43,8 @@ class TimeValue {
     constexpr static int64_t ONE_HOUR_SECONDS = 60 * ONE_MINUTE_SECONDS;
     constexpr static uint32_t MICROS_SCALE = 6;
     constexpr static int64_t MAX_TIME = 838 * ONE_HOUR_MICROSECONDS + 59 * 
ONE_MINUTE_MICROSECONDS +
-                                        59 * ONE_SECOND_MICROSECONDS; // 
838:59:59.000000
+                                        59 * ONE_SECOND_MICROSECONDS +
+                                        (ONE_SECOND_MICROSECONDS - 1); // 
838:59:59.999999

Review Comment:
   [P1] Preserve scale invariants when widening the TIME boundary
   
   This widened constant is used both as the representable limit and as the 
result of scale-agnostic saturation, but the consumers do not normalize to the 
declared result scale. On this head:
   
   - `CAST(CAST('838:59:59.999999' AS TIME(6)) AS TIME(0))` rounds and carries 
in `cast_to_date.h:319-339` to raw `3020400000000` (`839:00:00`), beyond this 
new maximum. Only a `DCHECK(TimeValue::valid(time))` catches it; release builds 
store it, while formatting clamps it back to `838:59:59` and `TIME_TO_SEC` 
exposes `3020400`.
   - Integer `SEC_TO_TIME` returns TIMEV2(0), but overflow now stores raw 
`3020399999999`. Widening that value to TIMEV2(6) exposes `.999999`, unlike a 
normal scale-0 endpoint, and raw equality/grouping/hash semantics can 
distinguish the identically rendered values. TIMEDIFF and TIME add/sub have the 
same problem when their result scale is below 6.
   
   This is distinct from the older extraction/folding threads: those 
current-head paths are aligned at scale 6; these failures are in scale 
reduction and lower-scale payloads. Please make rounding and saturation 
scale-aware (or enforce the chosen overflow semantics before storage) and cover 
both signs at scales 0-5 with raw equality and `TIME_TO_SEC` oracles.



##########
regression-test/data/correctness/test_time_function.out:
##########
@@ -75,7 +75,7 @@
 838:59:59.000000
 
 -- !select --
-838:59:59.000000
+838:59:59.999999

Review Comment:
   [P1] Regenerate the other saturation goldens
   
   The shared `limit_with_bound` change reaches existing overflow cases outside 
this suite. The two TIMEDIFF rows in 
`regression-test/data/nereids_function_p0/scalar_function/D.out:496,499` and 
the TIME(6) ADD_TIME row in 
`regression-test/data/query_p0/sql_functions/datetime_functions/test_date_function_v2.out:137`
 still expect `.000000`, but both implementations now return `.999999`. Please 
regenerate and include those results (in addition to the already-threaded 
TIME_FORMAT output); otherwise those full suites fail.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to