[fix](constant folding) Reject overflowing from_second and from_millisecond literals (#67037)

### What problem does this PR solve?

Related PR: #28685

Problem Summary:

`from_second` and `from_millisecond` widen their argument to
microseconds **before** the range check runs, so the multiplication can
wrap and land back inside the accepted range.

`fromSecond` computes `second.getValue() * 1000 * 1000` and hands the
result to `fromMicroSecond(long, int)`, whose guard is `microSecond < 0
|| microSecond > 253402271999999999L`. The guard therefore only ever
sees the wrapped product:

| Expression                              | Product                                | Wraps to | Folds to                          |
|-----------------------------------------|----------------------------------------|----------|-----------------------------------|
| `from_second(18446744073710)`           | `18446744073710 * 1000000`             | `448384` | `1970-01-01 00:00:00.448384`      |
| `from_millisecond(18446744073709552)`   | `18446744073709552 * 1000`             | `384`    | `1970-01-01 00:00:00.000384`      |

Both wrapped values sit inside `[0, 253402271999999999]`, so the guard passes.

`from_microsecond` passes its argument through unmultiplied and is
unaffected, which is why only the two widening wrappers are wrong.

These functions are registered for FE constant folding, so this is the
path a literal argument takes. The BE divides rather than multiplies
(`from_unixtime(value / Impl::ratio, ...)`) and rejects the same value,
so today the same expression errors over a column but folds to a bogus
datetime over a literal. #28685 fixed the BE side of this family in 2023
and did not touch the FE fold path.

### What is changed and how does it work?

The widening now goes through a small `toMicroSecond` helper that uses
`Math.multiplyExact` and converts the resulting `ArithmeticException`
into the same `AnalysisException` the range check already raises. An
overflowing literal now reports "out of range" instead of folding.

In-range arguments are unaffected, and negative arguments are still
rejected by the existing guard — both covered by the new tests.

### Release note

Fix `from_second` and `from_millisecond` returning a wrong datetime
instead of an out-of-range error for a literal argument large enough to
overflow when converted to microseconds.

Author: lets-order-some-fries

fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/DateTimeExtractAndTransform.java

@@ -1092,12 +1092,14 @@ public static Expression monthName(DateV2Literal date) {
 
     @ExecFunction(name = "from_second")
     public static Expression fromSecond(BigIntLiteral second) {
-        return fromMicroSecond(second.getValue() * 1000 * 1000, FromSecond.RESULT_SCALE);
+        return fromMicroSecond(toMicroSecond(second.getValue(), 1000L * 1000L, "from_second"),
+                FromSecond.RESULT_SCALE);
     }
 
     @ExecFunction(name = "from_millisecond")
     public static Expression fromMilliSecond(BigIntLiteral milliSecond) {
-        return fromMicroSecond(milliSecond.getValue() * 1000, FromMillisecond.RESULT_SCALE);
+        return fromMicroSecond(toMicroSecond(milliSecond.getValue(), 1000L, "from_millisecond"),
+                FromMillisecond.RESULT_SCALE);
     }
 
     @ExecFunction(name = "from_microsecond")
@@ -1117,6 +1119,23 @@ private static Expression fromMicroSecond(long microSecond, int scale) {
                 dateTime.getMinute(), dateTime.getSecond(), dateTime.getNano() / 1000);
     }
 
+    /**
+     * Widens {@code value} to microseconds without letting the multiplication wrap.
+     *
+     * <p>The range check lives in {@link #fromMicroSecond(long, int)}, which runs after the
+     * widening, so a product that overflows long can land back inside the accepted range: a
+     * literal argument then folds to a bogus datetime instead of being reported as out of range.
+     * The BE divides rather than multiplies and rejects the same argument, so only constant
+     * folding on the FE was affected.
+     */
+    private static long toMicroSecond(long value, long ratio, String functionName) {
+        try {
+            return Math.multiplyExact(value, ratio);
+        } catch (ArithmeticException e) {
+            throw new AnalysisException("Operation " + functionName + " of " + value + " out of range");
+        }
+    }
+
     @ExecFunction(name = "microseconds_diff")
     public static Expression microsecondsDiff(DateTimeV2Literal t1, DateTimeV2Literal t2) {
         return new BigIntLiteral(DateTimeV2Literal.datetimeDiffInMicroSeconds(t1, t2));

fe/fe-core/src/test/java/org/apache/doris/nereids/trees/expressions/functions/executable/DateTimeExtractAndTransformTest.java

@@ -209,4 +209,48 @@ void testConvertTzDstTransition() {
                         new VarcharLiteral("Europe/Paris"),
                         new VarcharLiteral("UTC")));
     }
+
+    // from_second and from_millisecond widen their argument to microseconds BEFORE the range
+    // check in fromMicroSecond runs. Without an overflow-checked multiply the product wraps back
+    // into the accepted range and folds to a bogus datetime instead of reporting the argument as
+    // out of range: 18446744073710 * 1_000_000 wraps to 448384, and 18446744073709552 * 1000
+    // wraps to 384. The BE rejects both, so only FE constant folding disagreed.
+    @Test
+    void testFromSecondRejectsOverflowingArgument() {
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(18446744073710L)));
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(Long.MAX_VALUE)));
+
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromMilliSecond(new BigIntLiteral(18446744073709552L)));
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromMilliSecond(new BigIntLiteral(Long.MAX_VALUE)));
+    }
+
+    // The pre-existing range check must keep rejecting a value that is out of range without
+    // overflowing, and negative arguments must still be rejected.
+    @Test
+    void testFromSecondStillRejectsOutOfRangeArgument() {
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(253402272000L)));
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(-20L)));
+        Assertions.assertThrows(AnalysisException.class,
+                () -> DateTimeExtractAndTransform.fromMilliSecond(new BigIntLiteral(-20L)));
+    }
+
+    // In-range arguments must still fold. The exact datetime depends on the session time zone,
+    // so this only asserts that folding happens and produces a datetime literal.
+    @Test
+    void testFromSecondStillFoldsInRangeArgument() {
+        Assertions.assertInstanceOf(DateTimeV2Literal.class,
+                DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(0L)));
+        Assertions.assertInstanceOf(DateTimeV2Literal.class,
+                DateTimeExtractAndTransform.fromSecond(new BigIntLiteral(1735689600L)));
+        Assertions.assertInstanceOf(DateTimeV2Literal.class,
+                DateTimeExtractAndTransform.fromMilliSecond(new BigIntLiteral(1735689600000L)));
+        Assertions.assertInstanceOf(DateTimeV2Literal.class,
+                DateTimeExtractAndTransform.fromMicroSecond(new BigIntLiteral(1735689600000000L)));
+    }
 }