The contract says: "Exit non-zero only on auth or network failure." But cronoclient.ParseDateRangeFromFlags returns an error (and the CLI exits 1) for purely-local input problems:
$ /tmp/crono-export biometrics --since 2026-04-20 --until 2026-04-15
error: --until (2026-04-15) is before --since (2026-04-20)
$ echo \"exit=$?\"
exit=1
$ /tmp/crono-export biometrics --since junk
error: bad --since: invalid date \"junk\" (use YYYY-MM-DD, today, yesterday, or Nd/Nw/Nm/Ny)
$ echo \"exit=$?\"
exit=1
That's arguably fine for unparseable input (programmer error, deserves exit 1). But the inverted-range case ("--until is before --since") is a request for an empty window, and a strict reading of the contract suggests it should yield exit 0 + empty output (the same as --since today --until today on a day with no logs).
At minimum:
- Decide and document which side of the line each input-validation error falls on.
- Make sure all five subcommands behave the same way (currently they all share the same parsing path, so this is already consistent — but worth pinning down before adding any per-command flags).
Also: the 2026-13-99 style "unparseable date" currently routes through the relative-date arm and emits invalid date unit \"9\": use d, w, m, or y which is a confusing error for what is obviously a malformed YYYY-MM-DD. Consider trying ParseInLocation first (already done) but failing with a better message when the string looks like a date but isn't.
Severity: minor
The contract says: "Exit non-zero only on auth or network failure." But
cronoclient.ParseDateRangeFromFlagsreturns an error (and the CLI exits 1) for purely-local input problems:That's arguably fine for unparseable input (programmer error, deserves exit 1). But the inverted-range case ("--until is before --since") is a request for an empty window, and a strict reading of the contract suggests it should yield exit 0 + empty output (the same as
--since today --until todayon a day with no logs).At minimum:
Also: the
2026-13-99style "unparseable date" currently routes through the relative-date arm and emitsinvalid date unit \"9\": use d, w, m, or ywhich is a confusing error for what is obviously a malformed YYYY-MM-DD. Consider trying ParseInLocation first (already done) but failing with a better message when the string looks like a date but isn't.Severity: minor