Skip to content

Print the actual reason a --changed-before/--changed-within date fails to parse - #2094

Open
MsfPablo wants to merge 1 commit into
sharkdp:masterfrom
MsfPablo:specific-date-parse-errors
Open

Print the actual reason a --changed-before/--changed-within date fails to parse#2094
MsfPablo wants to merge 1 commit into
sharkdp:masterfrom
MsfPablo:specific-date-parse-errors

Conversation

@MsfPablo

Copy link
Copy Markdown

Closes #2053.

--changed-before / --changed-within currently swallow the parse error and print the same generic message for every bad input:

$ fd -u --changed-before=2025-11-31
[fd error]: '2025-11-31' is not a valid date or duration. See 'fd --help'.

As the issue points out, that reads like a formatting problem, when the real problem is that November has 30 days.

TimeFilter::from_str discarded the jiff errors because it returned Option<SystemTime>. This changes TimeFilter::before/after to return Result<TimeFilter, String> and passes the reason through to the user:

$ fd -u --changed-before=2025-11-31
[fd error]: '2025-11-31' is not a valid date or duration: parsed date is not valid: parameter 'day' for `2025-11` is invalid, must be in range `1..=30`. See 'fd --help'.

$ fd --changed-within=foo
[fd error]: 'foo' is not a valid date or duration: failed to parse year in date: expected four digit year (or leading sign for six digit year), but found end of input. See 'fd --help'.

$ fd --changed-within=@x
[fd error]: '@x' is not a valid unix timestamp: expected '@' followed by a number of seconds since the epoch. See 'fd --help'.

The @-timestamp branch was also moved up so that an input starting with @ reports a timestamp error rather than falling through to the date parser and complaining about years.

Accepted inputs are unchanged; only the error paths differ. Added a unit test asserting the new messages, and updated the existing tests plus the CHANGELOG.

Verification (clean, and also clean on a git stash baseline):

cargo test                                  # 158 + 108 passed, 0 failed
cargo fmt --check                           # no output
cargo clippy --all-targets -- -D warnings   # no warnings

AI disclosure

Per CONTRIBUTING.md item 4: I used an AI coding assistant (Claude Code) for this change. It was used to locate the code path, draft the Option -> Result refactor in src/filter/time.rs and the matching call sites in src/main.rs, and to draft the unit test. I reviewed the diff, ran the commands above myself, and checked the resulting messages against the cases in the issue. I understand the change and can answer questions or revise it. The PR text is my own; AI was not used to write this description beyond assembling the command output above.

TimeFilter::before/after now return Result<_, String> instead of Option,
so the underlying jiff parse error reaches the user. An input like
2025-11-31 now says the day is out of range for that month rather than
only that the value is invalid.

Closes sharkdp#2053
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] fd should print more specific error messages for --changed- date parsing

1 participant