feat(calendar): add --sort / --order for events listing#581
Open
gado-ships-it wants to merge 1 commit into
Open
feat(calendar): add --sort / --order for events listing#581gado-ships-it wants to merge 1 commit into
gado-ships-it wants to merge 1 commit into
Conversation
`calendar events --all` aggregates events from every calendar, but the result was returned in calendar-iteration order (each calendar's events appear as a block, in the order CalendarList returned them). That makes the output unusable when an agent or user wants a single chronological view across calendars. Add `--sort=start|end|summary|calendar` plus `--order=asc|desc` to `calendar events`. With `--sort=start`, events from all calendars are interleaved by absolute instant (parsed via the existing parseEventTime / parseEventDate helpers, so RFC3339 with offset, RFC3339Nano, and all-day dates all compare correctly across timezones). Default `--sort=""` preserves prior behavior; the help string notes that `start` is the recommended value with `--all`. Also document `now` in the `--from` / `--to` help strings for both `calendar events` and the shared TimeRangeFlags. `timeparse` already resolves `now`, but the help only listed `today, tomorrow, monday`, so agents (and humans reading `--help`) had no signal that the precise "from this instant onward" form was available. Tests: - TestListAllCalendarsEvents_SortByStart asserts that events from two calendars interleave chronologically with --sort=start, and that --order=desc reverses the order. - TestSortEventsBy_Summary covers case-insensitive summary sort and reverse. - Existing TestListAllCalendarsEvents_JSON and TestListCalendarEvents_* continue to pass; their signatures gained two trailing empty strings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gog calendar events --allaggregates events from every calendar, but the result comes back in CalendarList iteration order (one calendar's events as a block, then the next). That makes the merged view unusable for agents/humans who want a single chronological list across calendars — the original motivation here was planning "today from now on" via an LLM agent.This PR:
--sort=start|end|summary|calendarand--order=asc|desctocalendar events. With--sort=start, events from all calendars interleave by absolute instant (parsed through the existingparseEventTime/parseEventDatehelpers so RFC3339 with offset, RFC3339Nano, and all-day2006-01-02dates compare correctly across timezones).nowin the--from/--tohelp strings for bothcalendar eventsand the sharedTimeRangeFlags.timeparse.ParseRangeExpralready resolvesnow, but the help only listedtoday, tomorrow, monday, so the precise "from this instant onward" form was invisible to anyone reading--help.wrapEventsWithTimezonehelper that lost its only call site after the JSON path was restructured to share wrapping with the table path.Default sort is empty so existing behavior is unchanged; the help string flags
startas the recommended value with--all.Example (placeholder data):
Test plan
make fmtcleanmake lintclean (no new issues)make testgreenTestListAllCalendarsEvents_SortByStartcovers--sort=start --order=asc+--order=descagainst a two-calendar fixture where the API returnslatebeforeearly.TestSortEventsBy_Summarycovers case-insensitive summary sort + reverse.+02:00,Z, and all-day formats.🤖