dongjoon-hyun opened a new pull request, #2698:
URL: https://github.com/apache/orc/pull/2698
### What changes were proposed in this pull request?
This PR aims to fix `AvroReader.TimestampConverter` to handle
`java.time.Instant` values produced by Avro 1.12.1.
- The converter now accepts both `java.time.Instant` (Avro 1.12.1+) and
`Long` (older behavior), extracting epoch milliseconds via
`Instant.toEpochMilli()` while preserving the existing `nanos = 0` behavior.
### Why are the changes needed?
Starting from Avro 1.12.1, decoding the `timestamp-millis` logical type
returns a `java.time.Instant` instead of a raw `Long`. The existing converter
cast the value directly to `Long`, causing a `ClassCastException` and breaking
`java-bench-scan-test`:
```
java.lang.ClassCastException: class java.time.Instant cannot be cast to
class java.lang.Long
at
org.apache.orc.bench.core.convert.avro.AvroReader$TimestampConverter.convert(AvroReader.java:192)
at
org.apache.orc.bench.core.convert.parquet.ParquetReader.nextBatch(ParquetReader.java:58)
at
org.apache.orc.bench.core.convert.ScanVariants.run(ScanVariants.java:92)
at org.apache.orc.bench.core.Driver.main(Driver.java:64)
```
Since `timestamp-millis` has millisecond precision, an `Instant`'s
sub-millisecond nanoseconds are always zero, so keeping `nanos = 0` preserves
the previous observable behavior.
### How was this patch tested?
Pass the CIs, including the previously failing `java-bench-scan-test`.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.8
--
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]
