TIME columns are never cast: needs_cast ignores a Time64 unit mismatch
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- data-visualization
Research direction
Start at src/plot/scale/scale_type/mod.rs:2205 and inspect the needs_cast logic for Time64 unit pairs. Run the SQL reproduction from the issue, then verify that mismatched time units are converted to the convention used by casting.rs and accepted by schema.rs. Audit the neighboring Timestamp arm as requested and confirm the reproduction produces Vega-Lite output without the Time64 error.
Written by the indexing model from the issue text.
Description
Summary
ggsql's Time convention is nanoseconds — casting.rs targets Time64(Nanosecond) and schema.rs reads through the strict as_time64_ns — but needs_cast (src/plot/scale/scale_type/mod.rs:2205) treats any (Time64(_), Time64(_)) pair as already being the target type, so DuckDB's native Time64(Microsecond) is never converted.
Reproduction
SELECT * FROM (VALUES (TIME '08:00:00', 1), (TIME '12:30:00', 4), (TIME '18:15:00', 2)) AS t(tm, v)
VISUALISE tm AS x, v AS y
DRAW point
Failed to generate Vega-Lite output: Internal error: Expected Time64(Nanosecond) array, got Time64(Microsecond)
The hephaestus writer does not error — it renders raw microsecond values against a domain ggsql could not resolve, which is worse.
Suggested fix
Treat a unit mismatch as needing a cast: (Time64(a), Time64(b)) is already-target only when a == b. The neighbouring (Timestamp(_, _), Timestamp(_, _)) arm has the same wildcard shape and should be audited at the same time.
- Dominant language
- Rust
- Stars
- 554
- Forks
- 30
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 15
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from posit-dev/ggsql
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
writer
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
bug plot building
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
documentation integration
Difficulty 1/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
trailofbits/dylint#2107 ·
Maintainers usually reply within 1 day
-
area:cli bug good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
arrays_zip with two same-named inputs fails with "ArrowArray struct has 2 children (expected 1)"Openbug requires-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/datafusion-comet#6251 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug false-positive harper-core linting
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Automattic/harper#4471 ·
Maintainers usually reply within 1 day