wombatu-kun opened a new pull request, #20519: URL: https://github.com/apache/hudi/pull/20519
### Describe the issue this Pull Request addresses Closes #20518 Part of #20449. ### Summary and Changelog Data skipping now treats `from_utc_timestamp(ts, tz)` and `to_utc_timestamp(ts, tz)` as order-preserving only when `tz` is a literal fixed-offset zone, so filters with a DST zone stop pruning files that hold matching rows. - `BaseHoodieCatalystExpressionUtils`: the `FromUTCTimestamp`/`ToUTCTimestamp` arms now require `isFixedOffsetTimeZone`, which resolves the zone with Spark's `DateTimeUtils.getZoneId`, as the functions do when evaluated, and checks `ZoneRules.isFixedOffset`. Any change of offset, DST or historical, breaks the ordering: local time runs backwards when it drops, and the gap of a rising offset shifts forward. - Tests: `TestDataSkippingUtils` covers both functions across `America/New_York` DST transitions next to a fixed-offset case that still prunes; `TestHoodieCatalystExpressionUtils` pins DST, fixed, short-ID, non-literal, null and unknown zones. ### Impact Correctness fix: such queries could silently miss rows, through both the column stats and the partition stats index. Filters with a region zone such as `America/New_York` or `Asia/Kolkata` no longer prune; fixed-offset zones such as `UTC`, `+08:00` or `GMT+8` still do. This is the mechanism behind the `to_utc_timestamp_gap` family and the `from_utc_timestamp` patterns of `dst_fall_back` in the #20439 oracle; that family's `date_format(ts, 'yyyy-MM-dd HH:mm')` pattern formats in the session zone and is not changed here. ### Risk Level low. It only removes pruning that was unsound. The new DST test cases fail without the fix, and the SQL repro from the issue returns the expected rows with it. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- 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]
