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.
Summary
ggsql's Time convention is nanoseconds —
casting.rstargetsTime64(Nanosecond)andschema.rsreads through the strictas_time64_ns— butneeds_cast(src/plot/scale/scale_type/mod.rs:2205) treats any(Time64(_), Time64(_))pair as already being the target type, so DuckDB's nativeTime64(Microsecond)is never converted.Reproduction
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 whena == b. The neighbouring(Timestamp(_, _), Timestamp(_, _))arm has the same wildcard shape and should be audited at the same time.