apache / apache/arrow-rs

[Variant] Align cast logic between `variant_get` and `cast` kernel for temporal types (Timestamp/Date/Time)

Open
#10,102 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
3.6k
Forks
1.3k
Avg merge
2d 18h
Merged PRs (30d)
169

Description

**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**

This is part of #8982 which wants to support the temporal types (`Timestamp*` incl. NTZ + timezone, `Date32`/`Date64`, `Time32*`/`Time64*`).

Currently the temporal cast logic in `parquet-variant-compute` (`type_conversion.rs`) hand-rolls conversion/truncation logic that *mimics* `arrow-cast` rather than reusing it. For example, several `Time*`/`Timestamp*` impls return `None` when there is leftover sub-second precision instead of truncating the way `arrow-cast` does (`lossy` is the default in the cast kernel).

**Describe the solution you'd like**

Align the logic of casting from/to the temporal types in `parquet-variant` with `arrow-cast` by reusing `arrow-cast`'s scalar conversion primitives (the same approach #9688 took for decimals, where `rescale_decimal` / `parse_string_to_decimal_native` / `single_float_to_decimal` were exposed and reused) instead of re-implementing the logic. This keeps a single source of truth for the cast semantics and lets the perfect-shredding fast path (`can_use_perfect_shredding_arrow_cast`, added in #9862) be widened to cover the truncating temporal pairs it currently excludes.

**Describe alternatives you've considered**

**Additional context**

cc @klion26 @AdamGS

Contributor guide

Open the contributing guide

Research direction

Start in parquet-variant-compute/type_conversion.rs and compare its temporal conversions with the scalar conversion primitives in arrow-cast. Review can_use_perfect_shredding_arrow_cast and the temporal pairs currently excluded; done means the conversions reuse arrow-cast semantics, including lossy sub-second truncation, and the perfect-shredding path covers the supported pairs.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
data, databases
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.