Mirrors are created with events.import, updated and deleted with
sendUpdates=none, so a write to an aggregate cannot mail anyone about a meeting
that was already invited from its source.
The import question the plan flagged is settled from Google's own API discovery
document rather than by guesswork: events.import accepts no sendUpdates parameter
at all, while insert, update and delete all do, and it is documented as adding "a
private copy of an existing event". A method with notification behaviour would
need that control. Confirmed live that attendees survive an import with their
response statuses intact.
Testing against the real API caught a defect that unit tests could not: the first
push dropped VALARM entirely and Google substituted the calendar's default
reminders. Alarms are never stripped by decision, so they now map to and from
Google's reminder overrides in both directions, with relative TRIGGER durations
converted to whole minutes. A trigger Google cannot express — absolute, or after
the start — is dropped rather than guessed at.
Known gaps recorded in TODO.md rather than papered over: a series' exceptions are
not pushed, since Google models those as separate events against an existing
series; and a failed Google pull still aborts the cycle, which is safe but stops
the CalDAV side too.
121 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Google equivalent of the pimsync pull, which pimsync cannot do: incremental
fetch by syncToken, converted to iCalendar and written into the endpoint's vdir.
A cursor Google no longer accepts comes back as 410, which means start again
rather than something broke, so that case refetches instead of failing.
The conversion was written against what the API actually returns, having probed
a real calendar first. Three findings shaped it:
- A recurring event's exceptions carry the same iCalUID as their master, so a
series belongs in one file, which is exactly the vdir convention.
- start.dateTime is an absolute instant while start.timeZone names the zone the
recurrence expands in, and the two need not agree: a real event reads
2023-10-31T13:00:00+02:00 with timeZone Asia/Karachi, which is +05:00.
Emitting the instant under that TZID unconverted would move it three hours, so
the instant is converted into its zone. That needs a timezone database, hence
jiff.
- A deleted occurrence arrives as an override with status cancelled. That is an
absence rather than an event, so it becomes an EXDATE on the master; moved
occurrences become RECURRENCE-ID events.
Timed values are written in UTC unless the event recurs. Only a recurrence needs
a zone to expand in, and confining TZID to those events limits how far we depend
on clients tolerating a TZID with no VTIMEZONE alongside it.
Verified against a live calendar: 30 real events, including a weekly series with
both a cancelled and several moved occurrences, converted and re-parsed intact.
The retarget tests no longer run a full cycle. They had used Google endpoints as
inert local stand-ins, which stopped being true the moment sync learned to
contact Google; they now reconcile directly.
115 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
