laserninja opened a new issue, #18115:
URL: https://github.com/apache/iceberg/issues/18115
### Apache Iceberg version
main (development), commit `c4784768b`
### Query engine
Other: Java API
### Please describe the bug
The same timestamp produces different microseconds depending on the
conversion path:
```java
String timestamp = "1969-12-31T23:59:59.999999999";
long direct =
Literal.of(timestamp).<Long>to(Types.TimestampType.withoutZone()).value();
long throughNanos =
Literal.of(timestamp).to(Types.TimestampNanoType.withoutZone())
.<Long>to(Types.TimestampType.withoutZone()).value();
```
Actual: `direct == 0`, `throughNanos == -1`.
`DateTimeUtil.microsFromInstant(Instant.parse(timestamp + "Z"))` also returns
`0`.
Expected: consistent floor-based precision reduction, matching
`DateTimeUtil.nanosToMicros`, which returns `-1`. At this boundary, the
inconsistency crosses into a different date.
The direct methods use `ChronoUnit.MICROS.between`, which truncates negative
fractional durations toward zero. They are used by literal parsing and generic
record conversion.
Proposed fix: align Instant, LocalDateTime, and OffsetDateTime microsecond
conversion with the existing floor-based nanosecond conversion, preserving the
full microsecond range and overflow checks. Include negative fractional values,
exact units, positive controls, and long-range boundary regressions.
### Willingness to contribute
- [x] I can contribute a fix for this bug independently
This report and its reproduction were prepared with AI assistance and
verified locally.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
