You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@paimon.apache.org by "LuciferYang (via GitHub)" <gi...@apache.org> on 2026/09/05 07:17:08 UTC

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

LuciferYang opened a new issue, #9621:
URL: https://github.com/apache/paimon/issues/9621

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/paimon/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:

```java
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:

```sql
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:

```java
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?

- [x] I'm willing to submit a PR!

--
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: issues-unsubscribe@paimon.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "LuciferYang (via GitHub)" <gi...@apache.org>.

LuciferYang commented on issue #9621:
URL: https://github.com/apache/paimon/issues/9621#issuecomment-5867045879

   @suntectec Thanks for the explanation.


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "LuciferYang (via GitHub)" <gi...@apache.org>.

LuciferYang closed issue #9621: [Bug] Numeric string cannot be cast to TIMESTAMP(1/2/4/5/7/8)
URL: https://github.com/apache/paimon/issues/9621


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "suntectec (via GitHub)" <gi...@apache.org>.

suntectec commented on issue #9621:
URL: https://github.com/apache/paimon/issues/9621#issuecomment-5866978054

   Thanks for looking into this @LuciferYang. Since the numeric epoch-string path intentionally supports only the standard units (second/milli/micro/nano → precision 0/3/6/9), and testInvalidPrecisions has deliberately treated 1/2/4/5/7/8 as unsupported since #5710, this is currently working as designed rather than a bug. Formatted timestamp strings already parse fine at those precisions. Following the maintainer's note on #9622, it would take a concrete producer/ingestion scenario plus an agreed input-unit contract (and an end-to-end test) to justify generalizing this. Without such a use case, I don't think we should push the PR forward — suggest we close this as won't-fix for now, and reopen if a real scenario shows up.


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org