Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

TIME columns are never cast: needs_cast ignores a Time64 unit mismatch

未关闭 适合新手
#515 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
rust

调研方向

从 src/plot/scale/scale_type/mod.rs:2205 开始,检查 Time64 单位对的 needs_cast 逻辑。运行 issue 中的 SQL 复现,然后验证不匹配的时间单位是否转换为 casting.rs 使用的约定,并被 schema.rs 接受。按要求审查相邻的 Timestamp 分支,并确认复现会生成不带 Time64 错误的 Vega-Lite 输出。

由索引模型根据 Issue 内容生成。

描述

plot building
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.

主要语言
Rust
星标
554
派生
30
平均合并
2 天 5 小时
30 天内合并 PR
15

环境准备

我们还没有检查这个项目的环境配置文件。先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

posit-dev/ggsql 的其他 Issue

查看 posit-dev/ggsql 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。