Environment

• gog version: 0.9.0 (Homebrew 2026-01-22)
• OS: Linux (Ubuntu/Debian-based)
• Installation: Homebrew

Issue

Creating recurring calendar events fails with Google API error: Missing time zone definition for start time, even though single (non-recurring) events work fine with the same datetime format.

Steps to Reproduce

1. Single event (works fine):
   export GOG_ACCOUNT="user@example.com"
   gog calendar create primary
   --summary "Test Event"
   --from "2026-02-13T08:00:00+02:00"
   --to "2026-02-13T09:00:00+02:00"
   ✅ Result: Event created successfully

2. Recurring event (fails):
   export GOG_ACCOUNT="user@example.com"
   gog calendar create primary
   --summary "Recurring Test"
   --from "2026-02-13T08:00:00+02:00"
   --to "2026-02-13T09:00:00+02:00"
   --rrule "FREQ=WEEKLY;BYDAY=TU,TH"
   --reminder "popup:30m"
   ❌ Result: Google API error (400 required): Missing time zone definition for start time.

Expected Behavior

Recurring events should work with the same datetime format that works for single events, especially since PR #53 (v0.5.0) fixed timezone handling for recurring events.

Actual Behavior

Recurring events fail even though:

• The datetime includes explicit timezone offset (+02:00)
• Single events work with the same format
• The fix was supposedly applied in v0.5.0
Workaround Attempts

Tried multiple datetime formats, all failed:

• 2026-02-13T08:00:00+02:00 (with offset)
• 2026-02-13T08:00:00 (without offset, relying on system TZ)
• Setting TZ=Africa/Johannesburg environment variable
All single-event variants work; all recurring variants fail.

Related

• PR #53 supposedly fixed this in v0.5.0
• Possible regression in later versions?
• Google Calendar API docs require explicit timeZone field for recurring events: https://developers.google.com/workspace/calendar/api/guides/recurringevents
Additional Context

The Google Calendar API example for recurring events shows:
{
"start": {
"dateTime": "2011-06-03T10:00:00.000-07:00",
"timeZone": "America/Los_Angeles"
},
"recurrence": [
"RRULE:FREQ=WEEKLY;UNTIL=20110701T170000Z"
]
}
It seems the API requires both the dateTime with offset AND an explicit timeZone field for recurring events, which might not be set when using --rrule.

Request

Could you verify if the timezone inference logic from PR #53 is still being applied when --rrule is present? There might be a code path that bypasses the fix for recurring events.