QA finding: when --since or --until looks like a date but doesn't parse (e.g. 2026-99-99, 2026-02-30, 2026-13-45), time.ParseInLocation fails silently and the value falls through to the relative-date parser (Nd/Nw/Nm/Ny). That parser then Sscanfs the leading digits, sees a non-{d,w,m,y} trailing char, and reports:
$ crono-export nutrition --since 2026-99-99
error: bad --since: invalid date unit "9": use d, w, m, or y
$ crono-export nutrition --since 2026-02-30
error: bad --since: invalid date unit "0": use d, w, m, or y
User typed a date, error talks about Nd/Nw/Nm/Ny "units" — confusing, especially 2026-02-30 (a valid-looking Feb 30 from a leap-year confusion).
Suggested fix in parseDateValue: if the value contains a - after position 0 (i.e., looks date-shaped), surface the time.ParseInLocation error rather than falling through. Something like:
if t, err := time.ParseInLocation(dateLayout, s, today.Location()); err == nil {
return t, nil
} else if strings.Contains(s[1:], "-") {
return time.Time{}, fmt.Errorf("invalid date %q: %w (expected YYYY-MM-DD)", s, err)
}Severity: minor (UX / error message clarity)
QA finding: when --since or --until looks like a date but doesn't parse (e.g. 2026-99-99, 2026-02-30, 2026-13-45), time.ParseInLocation fails silently and the value falls through to the relative-date parser (Nd/Nw/Nm/Ny). That parser then Sscanfs the leading digits, sees a non-{d,w,m,y} trailing char, and reports:
User typed a date, error talks about Nd/Nw/Nm/Ny "units" — confusing, especially 2026-02-30 (a valid-looking Feb 30 from a leap-year confusion).
Suggested fix in parseDateValue: if the value contains a
-after position 0 (i.e., looks date-shaped), surface the time.ParseInLocation error rather than falling through. Something like:Severity: minor (UX / error message clarity)