thswlsqls opened a new issue, #8644: URL: https://github.com/apache/paimon/issues/8644
**Search before asking** - [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. **Paimon version** master @ 711481bea **Compute Engine** Hive (3.1) **Minimal reproduce step** Read a pre-1970 TIMESTAMP that has a fractional second from a Paimon table through Hive 3.1, e.g. `SELECT` a column holding `1969-12-31 23:59:59.5`. `PaimonTimestampObjectInspector.getPrimitiveJavaObject()` (paimon-hive/paimon-hive-connector-3.1/.../objectinspector/PaimonTimestampObjectInspector.java line 43) computes `nanos = (int) (millis % 1000 * 1_000_000) + ...`. Paimon stores pre-epoch instants as a negative `millisecond`, so `millis % 1000` — and thus `nanos` — is negative. Hive 3.1 `Timestamp.ofEpochMilli(long,int)` then calls `LocalDateTime.withNano(nanos)`, which rejects a negative nano-of-second with `DateTimeException`. **What doesn't meet your expectations?** Expected: the value reads back as `1969-12-31 23:59:59.5`. Actual: the query fails with `DateTimeException`. **Anything else?** The sibling `paimon-hive-connector-common` inspector delegates to `Timestamp.toSQLTimestamp()` / `java.sql.Timestamp`, which handles negative epoch millis correctly; only the Hive 3.1 override does the manual arithmetic. `Math.floorMod(millis, 1000L)` keeps the sub-second nanos in `[0, 999_999_999]` and leaves the positive path unchanged. **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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
