[Bug] Numeric string cannot be cast to TIMESTAMP(1/2/4/5/7/8)

Start with BinaryStringUtils.toTimestamp and reproduce the numeric-string conversion using precision 4, then compare it with the existing supported precision cases. Verify that numeric strings work for every legal TIMESTAMP precision from 0 through 9, while the existing date-shaped conversions remain unchanged.

Search before asking

• I searched in the issues and found nothing similar.

Paimon version

master, 475be566f (2.1-SNAPSHOT).

Compute Engine

Any. The cast runs in BinaryStringUtils, reached from column default values, partition value parsing, filter literals pushed down from Flink and Spark, CDC ingestion and the Hive output format.

Minimal reproduce step

Cast a numeric string to a TIMESTAMP whose precision is not 0, 3, 6 or 9:

BinaryStringUtils.toTimestamp(BinaryString.fromString("1700000000"), 4);
// java.lang.RuntimeException: Unsupported precision: 4

TimestampType accepts 0 through 9 (MIN_PRECISION 0, MAX_PRECISION 9) and validates nothing else, so TIMESTAMP(4) is a legal column type. A table with such a column reaches this through, for example, a default value:

CREATE TABLE t (id INT, ts TIMESTAMP(4)) WITH ('fields.ts.default-value' = '1700000000');

The same string at precision 3, 6 or 9 converts fine, and a date-shaped string like '2026-01-15 10:00:00' converts fine at precision 4 as well, because that goes down a different path. It is only the numeric fast path that rejects the precision:

switch (precision) {
    case 0: ...
    case 3: ...
    case 6: ...
    case 9: ...
    default:
        throw new RuntimeException("Unsupported precision: " + precision);
}

What doesn't meet your expectations?

Six of the ten legal precisions cannot take a numeric string. There is nothing special about them: the value counts units of 10^-precision seconds, so one unit is 10^(3 - precision) milliseconds, and the four implemented cases are just that formula at four points. Precisions 1, 2, 4, 5, 7 and 8 are the same arithmetic with a different power of ten.

Anything else?

Nothing in the method guards against overflow for the low precisions (epoch * 1000 at precision 0 wraps for a large enough string), which is pre-existing and unrelated to which precisions are accepted.

Are you willing to submit a PR?

• I'm willing to submit a PR!