feat(calendar): add --timezone display override to events and event#908
Closed
bxxd wants to merge 2 commits into
Closed
feat(calendar): add --timezone display override to events and event#908bxxd wants to merge 2 commits into
bxxd wants to merge 2 commits into
Conversation
Google returns event times in each calendar's timezone, and since openclaw#493 the table output and startLocal/endLocal JSON fields render calendar-local. That is the right default, but it has a hole: calendars whose own timezone is UTC (ICS/SportsEngine feed imports, calendars created with default settings) display UTC wall-clock with no way to see the times where the viewer lives — an 8:45am practice stored on a UTC-timezone calendar lists as 12:45Z. Add --timezone/--tz to 'calendar events' and 'calendar event' as an explicit display override (IANA name, or 'local' for the system timezone). Empty keeps the current per-calendar behavior. When set, the override applies uniformly across --all/--cal listings and skips the per-calendar timezone lookups. Range parsing (--from/--to/--today) is unchanged. Display-only, orthogonal to openclaw#905 (event-vs-calendar timezone preference).
Contributor
|
Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 8:30 AM ET / 12:30 UTC. Summary Reproducibility: not applicable. as a strict bug reproduction: this is a feature PR for a new display override. Source inspection confirms current main and v0.33.0 do not expose that flag, while the PR body gives live output for the motivating UTC-calendar workflow. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Land the additive display-only override if maintainers accept the flag surface, while preserving calendar-local defaults and keeping event-timezone preference work separate. Do we have a high-confidence way to reproduce the issue? Not applicable as a strict bug reproduction: this is a feature PR for a new display override. Source inspection confirms current main and v0.33.0 do not expose that flag, while the PR body gives live output for the motivating UTC-calendar workflow. Is this the best way to solve the issue? Yes, pending maintainer API acceptance. The patch keeps the default calendar-local behavior, adds an explicit display-only override, and fixes the prior single-event weekday mismatch with a focused regression. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a1977274de23. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
There was a problem hiding this comment.
Pull request overview
Adds a display-only timezone override to the calendar read commands so users (and automations) can force all rendered event times into a single viewer timezone without changing how events are stored or how time ranges are parsed.
Changes:
- Add
--timezone/--tztogog calendar eventsandgog calendar eventto override displayed event times (IANA zone orlocal). - Thread a resolved display-timezone hint through event listing/single-event paths, skipping per-calendar timezone lookups when an override is set.
- Add regression + wiring tests and regenerate command docs.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| internal/cmd/calendar_zoom_test.go | Updates helper call signature for listCalendarEvents to include the new display timezone parameter. |
| internal/cmd/calendar_list.go | Adds display timezone override plumbing (displayTimezoneOverride, calendarDisplayTimezone override parameter) and threads it through list paths. |
| internal/cmd/calendar_events_test.go | Refactors test handler for reuse and adds coverage for override behavior, invalid/empty values, and “skip calendar lookups” behavior. |
| internal/cmd/calendar_events_cmds.go | Wires --timezone/--tz into calendar events and calendar event commands and applies the override at render time. |
| internal/cmd/calendar_changed.go | Updates calendarDisplayTimezone call sites for the new function signature. |
| internal/cmd/calendar_all_events_test.go | Updates listAllCalendarsEvents call sites for the new display timezone parameter. |
| docs/commands/gog-calendar-events.md | Documents the new --timezone/--tz flag for calendar events. |
| docs/commands/gog-calendar-event.md | Documents the new --timezone/--tz flag for calendar event and updates usage to include [flags]. |
| docs/commands.generated.md | Regenerates the command index entry to reflect calendar event now accepting flags. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ation Review follow-up: printCalendarEventWithTimezone formatted start-local/ end-local in the resolved display location but still computed start-day-of-week/end-day-of-week without it, so an instant that changes date in the override timezone could print a mismatched weekday. Use eventDaysOfWeekInLocation with the same resolved location (matching the JSON path) and add a CalendarEventCmd regression where the override crosses midnight (02:00Z Wednesday -> 22:00 Tuesday America/New_York).
Author
|
Both review findings addressed in 02492b1:
|
clawsweeper
Bot
added
proof: sufficient
steipete
added a commit
that referenced
this pull request
Jul 11, 2026
Co-authored-by: bxxd <[email protected]>
Collaborator
|
Landed on Maintainer follow-up integrated the event-timezone behavior from #905 and added explicit precedence coverage: |
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
--timezone/--tztocalendar eventsandcalendar event: an explicit display-timezone override (IANA name, orlocalfor the system timezone)--all/--cal/--calendarslisting renders uniformly, and the per-calendar timezone lookups are skipped (they'd be unused)Why
Real-world failure that motivated this: a household agent builds a daily schedule from
calendar events --all -j. Two of the account's nine calendars have their calendar timezone set to UTC — one is a SportsEngine ICS feed import (import calendars commonly come in as UTC and can't be re-zoned), one a Google calendar created with default settings. Google returns their event times in the calendar's timezone, and since #493 the table output andstartLocal/endLocalJSON fields render calendar-local — which for these calendars is UTC:That 12:45Z is an 8:45am (America/New_York) swim practice. The agent published the family's schedule shifted +4h — swim at "12:45p", an evening practice that was actually 4pm. The stored instants are all correct; there is just no way today to ask the CLI to display them where the viewer lives.
--timezonecloses that hole while keeping #493's calendar-local default:Notes:
--from/--to/--todayrange parsing is unchanged (still the primary calendar's timezone).gmail messages --timezone) and the calendar write-side--timezone/--tzaliases (feat(calendar): add --timezone flag to event create #844).Test plan
make fmt,make lint(0 issues),go test ./internal/...— all packages pass/calendars/<id>lookups (test handler deliberately 404s them); invalid value → usage error exit 2; empty value → no override; Kong-level flag wiring end-to-endmake docs-commandsregenerated🤖 Implemented with Claude Code, human-reviewed before submission.