filter_breaks_to_range cannot filter temporal breaks, so out-of-domain ticks survive
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- data-visualization
Research direction
Start in src/plot/scale/breaks.rs at filter_breaks_to_range around line 292, then compare its numeric handling with the minor-breaks path's use of ArrayElement::to_f64(). Done means temporal breaks outside the resolved domain are removed while values without a numeric projection retain the current pass-through behavior; verify with the Date scale reproduction in the issue.
Written by the indexing model from the issue text.
Description
This issue was surfaced during the Hephaestus writer work
Summary
filter_breaks_to_range (src/plot/scale/breaks.rs:292) returns the break list unchanged unless both range endpoints are ArrayElement::Number, and inside the predicate it explicitly keeps any break that is not a Number. A Date / DateTime / Time scale therefore never gets filtered: a calendar-aligned major computed outside the resolved domain survives, and both writers place a tick off-panel.
Reproduction
VISUALISE Date AS x, Temp AS y FROM ggsql:airquality
DRAW line
SCALE x SETTING breaks => '2 months'
domain: ['1973-04-23', '1973-10-07']
values: ['1973-04-01', '1973-06-01', '1973-08-01', '1973-10-01', '1973-12-01']
1973-04-01 and 1973-12-01 are both outside the resolved domain.
Suggested fix
Filter on ArrayElement::to_f64() for the range endpoints and the breaks alike — which is exactly what the minor breaks path already does — falling back to the current pass-through only when a value has no numeric projection.
- Dominant language
- Rust
- Stars
- 554
- Forks
- 30
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 18
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
posit-dev/ggsql#565 · 2 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
writer
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
plot building
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
documentation integration
Difficulty 1/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
trezor/trezor-firmware#7997 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
oxidecomputer/management-gateway-service#506 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
scylladb/nodejs-rs-driver#566 ·
Maintainers usually reply within 1 day
-
A-ABI needs-triage relnotes relnotes-needs-review relnotes-tracking-issue T-lang T-libs T-opsem
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day