[common] Range-check the digit guard in DateTimeUtils

[LuciferYang]

Purpose

close #9648

DateTimeUtils.parseDate and parseTime return null for input they cannot parse, and they guard every Integer.parseInt with isInteger. That guard only checked the characters:

private static boolean isInteger(String s) {
    boolean isInt = s.length() > 0;
    for (int i = 0; i < s.length(); i++) {
        if (s.charAt(i) < '0' || s.charAt(i) > '9') {
            isInt = false;
            break;
        }
    }
    return isInt;
}

A component of eleven digits therefore passed it and Integer.parseInt threw NumberFormatException, escaping a method whose every other failure path returns null. parseDate("2147483648-01-01") and parseTime("2147483648:00:00") both do it.

The guard now also checks the range, which is enough because it sits in front of each of the eleven parseInt calls in those two methods. Nothing else changes: no signature, no local variable type, no arithmetic.

Callers see the difference as an exception type. Through the casts, NumberFormatException becomes the DateTimeException that BinaryStringUtils.toDate raises for any unparseable string, which is what a caller already gets for "99999-01-01" (rejected by isIllegalDate) or "not-a-date". The Hive PaimonTimeObjectInspector.convert passes the Integer through, so a TIME column holding such a value writes NULL rather than failing, matching what it already does for other invalid times.

Tests

DateTimeUtilsTest.testParseDateAndTimeOverflowReturnsNull covers a too-large year, month, day and hour, and the two boundary cases: 2147483648 is the smallest ten-digit value that does not fit an int, and 2147483647 does fit but is still not a valid year, so both have to come back null through different branches. Valid values are asserted alongside them.

Against the unfixed guard the test errors with NumberFormatException: For input string: "2147483648".

mvn -pl paimon-common -Dtest=DateTimeUtilsTest test on JDK 8: 12 tests, 0 failures. spotless:check and checkstyle:check on paimon-common are clean.

[JingsongLi]

The overflow guard has a real caller through Hive's TIME conversion, and the 12 DateTimeUtils tests pass with the changed class. There is a narrow compatibility regression in the new length shortcut that should be addressed without changing accepted numeric values.

[JingsongLi]

[P2] Range-check the value without rejecting leading zeros. This length limit rejects components whose numeric value still fits an int: parseDate("00000002024-01-01") and parseTime("00000000012:30:00") return 19723 and 45000000 on the base revision, but both return null with this change (confirmed in an isolated base/head probe). Through PaimonTimeObjectInspector.convert, previously accepted zero-padded TIME values are therefore silently replaced with NULL. Ignore leading zeros for the range check, or use an overflow-checked accumulator, and add regression coverage alongside the genuinely out-of-range inputs.

[JingsongLi]

Requirement fit: SUPPORTED. Implementation: CLEAN in the reviewed scope.

The overflow-checked accumulator addresses the earlier compatibility regression: long zero-padded components retain their accepted numeric values, while values above Integer.MAX_VALUE return the existing parse-failure sentinel. The accumulator exits before it can overflow a long. This preserves the Hive TIME conversion behavior for valid padded inputs and handles malformed overflow inputs consistently.

DateTimeUtilsTest passed all 12 cases with the changed class on JDK 8, including padded dates/times and actual overflow. No new blocking defect found; Hive integration was not executed.

[LuciferYang]

Thank you @JingsongLi