[Bug] Numeric string cannot be cast to TIMESTAMP(1/2/4/5/7/8)
- Dominant language
- Java
- Stars
- 3.4k
- Forks
- 1.4k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 396
Description
### 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!
Contributor guide
No contributing guide indexed for this repository
Research direction
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.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100