apache / apache/paimon

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

Open Beginner friendly
#9,621 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.