kz930 opened a new pull request, #9076: URL: https://github.com/apache/texera/pull/9076
### What changes were proposed in this PR? `IcebergUtil.toGenericRecord` stored a TIMESTAMP field by turning the `java.sql.Timestamp` into an instant and back into a wall clock in the machine's zone. The two steps follow different zone rules. A Timestamp gives a date before 1900 the zone's standard offset, and `java.time` reads the instant back with the zone's full history, which is local mean time before 1883. In America/Los_Angeles a stored `1600-06-15 08:30:00` came back as `08:37:02`. The field is now stored as `ts.toLocalDateTime`, the wall clock the Timestamp holds. `fromRecord` already reads it back with `Timestamp.valueOf`, which is its inverse, so a value comes out of result storage as it went in. Timestamps after 1883 are unchanged, since both rules agree there. ### Any related issues, documentation, discussions? Closes #9074. ### How was this PR tested? A test in `IcebergUtilSpec` sets the default zone to America/Los_Angeles, stores `1600-06-15 08:30:00` and `1677-09-21 00:00:00`, and checks that the record holds each wall clock and reads back to the same tuple. The zone is set in the test because UTC has no local mean time, so the old conversion passes there. On the old code the test fails with `1600-06-15T08:37:02 did not equal 1600-06-15T08:30`. All 24 tests in the spec pass. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5.5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
