Repository navigation
--since/--until accept invalid dates and silently return wrong results #1483
Description
What happened?
--since and --until are documented as YYYY-MM-DD or YYYYMMDD, but a value that is neither is not rejected. The bound is normalized with value.replace('-', "") and then compared as a plain string against the YYYYMMDD row keys, so an invalid bound either turns the filter into a no-op or drops every row. Exit code is 0 in all cases, so a script has no way to notice.
normalize_date_bound (rust/crates/ccusage-cli/src/types.rs:70) is the whole normalization:
pub fn normalize_date_bound(value: &str) -> String {
value.replace('-', "")
}and filter_and_sort_summaries (rust/crates/ccusage/src/summary.rs:277) compares the result as a string, so nothing checks that the bound is a real date.
This is the same failure shape as #1108, which fixed the dashed format but did not add validation.
Steps to reproduce
Local data spanning 2026-05-05 to 2026-07-24, 34 daily rows.
| command | rows returned | expected |
|---|---|---|
ccusage daily --since 2026-02-30 |
34 (all) | error |
ccusage daily --since 2026-13-01 |
0 | error |
ccusage daily --since abc |
0 | error |
ccusage daily --since 2026/07/10 |
34 (all) | error |
ccusage daily --until 2026-02-30 |
0 | error |
ccusage daily --until 2026-13-01 |
34 (all) | error |
ccusage daily --until abc |
34 (all) | error |
--until is the mirror of --since because the comparison is lexicographic. abc sorts after any 2026... string, 20260230 sorts before every row in range, and 2026/07/10 keeps its slashes, which sort before digits.
One more case: --since 2026-07-10T00:00:00Z normalizes to 20260710T00:00:00Z, which sorts after 20260710, so it silently drops 2026-07-10 itself and the report starts at 2026-07-11.
Expected behavior
An invalid bound should be rejected with a message naming the flag, and a non-zero exit.
A bound could be accepted only if it matches one of the two documented forms and is a real calendar date. Date::from_ymd (rust/crates/ccusage/src/date_utils.rs:81) already does the calendar check including leap years. Config-file bounds call the same function (rust/crates/ccusage/src/config.rs:527), so they would need the same check.
normalize_date_bound has no direct unit tests right now, so the cases above could be added there.
I would like to implement this myself if the approach sounds right.
Version
20.0.18, and also reproduced with a release build of main @ 31e084a.
Activity
pullfrog commentedon Jul 24, 2026
github-actions commentedon Jul 24, 2026
This issue was auto-closed. Issues from new contributors are auto-closed by default.
Maintainers review auto-closed issues and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md may not be reopened or receive a reply.
Keep the issue short, concrete, and written in your own voice.
If a maintainer replies
lgtmi, your future issues will stay open. If a maintainer replieslgtm, your future issues and PRs will stay open.See CONTRIBUTING.md.
LeeYudok commentedon Jul 27, 2026
Implementation is up at #1502. The PR gate auto-closed it since I am not in
APPROVED_CONTRIBUTORSyet — the branch and diff are intact, so reopening it is enough if the approach looks right.Summary of what changed versus the approach in this issue: the crate split means
ccusage-clicannot reachIsoDate::from_ymdinccusage-core, sinceccusage-cliis dependency-free by design and sits on every adapter's critical path. The calendar check is implemented locally there instead. Config-file bounds are validated inConfigContext::from_argsand surface through the existingconfig_errorchannel, becauseapply_shared_optionscannot fail.One judgment call worth your input:
--since 2026-07-10T00:00:00Zis rejected rather than truncated to20260710. It is not one of the documented formats and it was silently dropping that day, but I am happy to accept and truncate instead.mr-tiwari-ji commentedon Aug 5, 2026
Hi @ryoppippi ,
I am facing an issue while using the instances option, According to the documentation, the
dailycommand supports the--instances(or-i) option to group usage by project. However, on ccusage v20.0.19, the CLI reports:Unknown option '--instances'
The
--instancesoption should be recognized and group daily usage by project instead of aggregating across all projects, as documented.ryoppippi commentedon Aug 31, 2026
Historical audit: this discussion was auto-closed by the legacy contributor gate. That closure did not assess technical importance.
Audit result: resolved. A later merged change or the current
mainimplementation covers this request. This item is kept for history and does not need to be reopened.