[Part1] [ORC-timezone]: Build ORC timezone metadata at runtime, drop pregenerated binary

[res-life]

First in a stack splitting #4432 into reviewable chunks.

Description

Previously OrcTimezoneInfo loaded its transition tables from a pregenerated 544KB binary (src/main/resources/orc_timezone_info.data, derived from sun.util.calendar.ZoneInfo on OpenJDK 8). This froze ORC timezone behavior to that snapshot and required regenerating and committing the binary whenever the data needed to change.

This PR replaces the binary with a runtime build path:

• buildHistoricalTransitions walks ZoneRules.getTransitions() from year 0001 (the lower bound ORC supports) and probes TimeZone.getOffset() to capture the offset before each known transition.
• collectTimeZoneTransitionsByScanning covers any gap between two known transitions by stepping forward at 1-day granularity and binary-searching the exact transition millisecond when an offset change is detected.
• Per-id results are cached in RUNTIME_TIMEZONE_INFOS.
• getAllTimezoneIds() now returns the live TimeZone.getAvailableIDs() instead of a hard-coded array.

OrcTimezoneInfo keeps its (rawOffset, transitions, offsets) shape so the CUDA kernel is unchanged. DST timezones remain blocked by the existing hasDaylightSavingTime guard in convertOrcTimezones — follow-up PRs lift this guard:

1. (this PR) Build OrcTimezoneInfo at runtime
2. DST rule extraction (Java side, CPU verified)
3. GPU DST kernel + new convertOrcTimezones signature
4. OrcTimezoneContext + remaining tests

isSupportedTimeZone is broadened from catch (ZoneRulesException) to catch (DateTimeException) so IDs like +05:30 are rejected/accepted consistently with the runtime build path (ZoneId.of may throw either, depending on whether the id has a malformed offset vs. an unknown name).

Checklists

• Documentation: no user-facing change.
• Tests: behavior preserved for non-DST timezones; covered by existing tests in this repo and the companion spark-rapids PR.
• Performance: no expected change for the existing non-DST path. The first call per timezone pays a one-time runtime-build cost (measured ~4 ms typical, ~12 ms worst on the previous full-DST iteration); subsequent calls hit the cache.

Signed-off-by: Chong Gao chongg@nvidia.com

[nvauto]

NOTE: release/26.06 has been created from main. Please retarget your PR to release/26.06 if it should be included in the release.

[res-life]

build

[res-life]

build

[greptile-apps]

Greptile Summary

This PR replaces a frozen 544 KB pregenerated binary (orc_timezone_info.data) with a runtime build path that derives ORC timezone metadata from public java.time/java.util APIs. Results are cached per ID in a ConcurrentHashMap, the timezone-ID list now comes from the live JVM tzdata, and isSupportedTimeZone broadens its catch to DateTimeException so offset-style IDs are handled consistently.

• OrcTimezoneInfo is completely rewritten: buildHistoricalTransitions walks ZoneRules.getTransitions() from year 0001, while collectTimeZoneTransitionsByScanning fills any gap using exponential probing + binary search; a fixed-offset fast path handles +HH:MM-style IDs correctly (the old TimeZone.getTimeZone() would have silently mapped them to GMT).
• GpuTimeZoneDB gains two new tests covering the DateTimeException-widening regression and the no-GMT-fallback contract; getOrcSupportedTimezones Javadoc is updated to reflect the pre-filtered list.
• OrcTimezoneInfoTest is added with unit coverage for fixed-offset zones, cache identity, invalid-ID rejection, strict monotonicity of the generated transition table, and the getAllTimezoneIds sort/distinct/filter contract.

Confidence Score: 5/5

Safe to merge for the non-DST path; the existing DST guard in convertOrcTimezones keeps the one documented scan limitation dormant until a follow-up PR lifts it.

The core algorithms (exponential expand + binary search, fixed-offset fast path, canonical ID resolution via zoneId.getId()) are well-reasoned and the previous thread concerns have all been addressed. The only residual limitation — an A→B→A paired transition within the 6 h scan step — is explicitly documented in comments and is unreachable in practice because the DST guard blocks the code path that would exercise it. No new logic errors were found in the scanning, cache, or test coverage.

OrcTimezoneInfo.java (the new runtime build path) and OrcTimezoneInfoTest.java (test contract strength) are the files worth a close second read.

Important Files Changed

Filename	Overview
src/main/java/com/nvidia/spark/rapids/jni/OrcTimezoneInfo.java	Complete rewrite replacing a 544 KB pregenerated binary with a runtime build path using ZoneRules + TimeZone.getOffset(). Key algorithms: exponential-expand probe + binary search for the gap scan, per-ID ConcurrentHashMap cache, and a fixed-offset fast path. Logic is sound for non-DST zones; an acknowledged A→B→A paired-transition gap in the exponential scan is kept dormant by the DST guard in convertOrcTimezones.
src/main/java/com/nvidia/spark/rapids/jni/GpuTimeZoneDB.java	Minimal targeted changes: isSupportedTimeZone now catches the broader DateTimeException instead of just ZoneRulesException (so offset-style IDs like "+25:00" are consistently rejected), a comment on the fixed-offset null-check is removed, and the getOrcSupportedTimezones Javadoc is updated to describe the pre-filtered contract.
src/test/java/com/nvidia/spark/rapids/jni/OrcTimezoneInfoTest.java	New test class covering: fixed-offset zones (+05:30, UTC), cache identity, invalid-ID contract, getAllTimezoneIds sort/distinct/pre-filter contract, and strict-monotonicity of transitions for Asia/Shanghai. The getAllTimezoneIds contract test verifies isSupportedTimeZone() for each ID rather than calling OrcTimezoneInfo.get() directly.
src/test/java/com/nvidia/spark/rapids/jni/GpuTimeZoneDBTest.java	Adds testIsSupportedTimeZone (covers the DateTimeException widening for offset IDs) and testConvertOrcTimezonesRejectsInvalidId (regression guard for the no-silent-GMT-fallback contract).
src/main/resources/orc_timezone_info.data	Deleted 544 KB pregenerated binary; all its data is now derived at runtime. Deletion is correct — the binary is no longer referenced anywhere.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant OrcTimezoneInfo
    participant Cache as RUNTIME_TIMEZONE_INFOS
    participant GpuTimeZoneDB
    participant ZoneRules
    participant TimeZone

    Caller->>OrcTimezoneInfo: get(timezoneId)
    OrcTimezoneInfo->>Cache: computeIfAbsent(timezoneId)
    alt cache hit
        Cache-->>OrcTimezoneInfo: cached OrcTimezoneInfo
    else cache miss
        OrcTimezoneInfo->>GpuTimeZoneDB: getZoneId(timezoneId)
        GpuTimeZoneDB-->>OrcTimezoneInfo: ZoneId (or DateTimeException)
        OrcTimezoneInfo->>ZoneRules: getRules() → isFixedOffset()?
        alt fixed offset
            OrcTimezoneInfo-->>Cache: OrcTimezoneInfo(fixedOffsetMs, null, null)
        else historical zone
            OrcTimezoneInfo->>TimeZone: getTimeZone(zoneId.getId())
            OrcTimezoneInfo->>ZoneRules: getTransitions()
            OrcTimezoneInfo->>OrcTimezoneInfo: buildHistoricalTransitions(tz, transitions)
            loop "each ZoneOffsetTransition >= year 0001"
                OrcTimezoneInfo->>TimeZone: getOffset(transitionMs-1)
                alt gap detected (offset mismatch)
                    OrcTimezoneInfo->>OrcTimezoneInfo: collectTimeZoneTransitionsByScanning(exponential expand + binarySearch)
                end
                OrcTimezoneInfo->>TimeZone: getOffset(transitionMs)
            end
            OrcTimezoneInfo-->>Cache: OrcTimezoneInfo(rawOffset, transitions[], offsets[])
        end
        Cache-->>OrcTimezoneInfo: new OrcTimezoneInfo
    end
    OrcTimezoneInfo-->>Caller: OrcTimezoneInfo

Loading

_{Reviews (5): Last reviewed commit: "Use canonical zone id when looking up Ti..." | Re-trigger Greptile}

[res-life]

@greptile-apps review

[res-life]

build

[firestarman]

LGTM