fix(calendar): interpret date-only --to values as end of day#204
fix(calendar): interpret date-only --to values as end of day#204mjaskolski wants to merge 2 commits intoopenclaw:mainfrom
Conversation
When --to is given a date-only value like '2026-02-02' or a relative expression like 'tomorrow', parse it as end of day (23:59:59.999) instead of start of day (00:00:00). This fixes the issue where '--from 2026-02-02 --to 2026-02-02' returns no events because both values resolve to the same midnight timestamp, creating a zero-length query window. The --today/--tomorrow convenience flags already handled this correctly by using endOfDay() for the 'to' bound. This change applies the same logic to date-only and relative --to values parsed via parseTimeExpr. Full RFC3339 timestamps with explicit times are preserved as-is. Fixes openclaw#155
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 37a8e5ead4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // If the result is exactly midnight (start of day), it was likely a date-only | ||
| // or relative day expression — adjust to end of day. | ||
| if t.Hour() == 0 && t.Minute() == 0 && t.Second() == 0 && t.Nanosecond() == 0 { | ||
| return endOfDay(t), nil |
There was a problem hiding this comment.
Preserve explicit midnight timestamps for --to
The new end-of-day adjustment triggers whenever the parsed time is exactly midnight, which also includes explicit RFC3339 timestamps like 2025-01-05T00:00:00Z. That means a user who intentionally specifies an exact midnight end time will silently get 23:59:59.999 instead, expanding the query window beyond what they asked for. This contradicts the stated intent to preserve full RFC3339 timestamps and will mis-handle any --to values that are intentionally midnight. Consider gating the adjustment on the original expression format (e.g., only date-only/relative inputs) instead of the parsed time value alone.
Useful? React with 👍 / 👎.
Previously parseTimeExprEndOfDay() checked if the parsed time was exactly midnight to decide whether to adjust to end-of-day. This incorrectly caught explicit RFC3339 timestamps like --to 2025-01-05T00:00:00Z where the user intentionally specified midnight. Now the function checks the raw input string format instead: - Date-only (YYYY-MM-DD), relative keywords (today/tomorrow/yesterday), and weekday names → adjusted to end of day (23:59:59.999999999) - Full timestamps (RFC3339, ISO8601, local datetime with T) → preserved as-is Addresses Codex review feedback on PR openclaw#204.
Land #204 and preserve point-in-time semantics for --to now. Co-authored-by: Michal Jaskolski <mjaskolski@users.noreply.github.com>
|
Landed on Thanks @mjaskolski for the PR. |
|
Closing as landed via commit 16fdf07 on main. |
Land openclaw#204 and preserve point-in-time semantics for --to now. Co-authored-by: Michal Jaskolski <mjaskolski@users.noreply.github.com>
Summary
When
--tois given a date-only value like2026-02-02or a relative expression liketomorrow, it was parsed as start of day (00:00:00), creating a zero-length query window when paired with the same--fromdate. This meant--from 2026-02-02 --to 2026-02-02returned no events.Fix
Added
parseTimeExprEndOfDay()which wrapsparseTimeExpr()and adjusts date-only/relative results to end of day (23:59:59.999). The--toflag now uses this function.This matches the behavior of
--today/--tomorrowconvenience flags which already usedendOfDay()correctly.What's preserved
--fromstill resolves to start of day (correct for range starts)Fixes #155