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>
Moving an aggregate to a different endpoint is the sharpest failure mode in the
design, so it is a command rather than something a config edit triggers: sync
already refuses on target drift and points here.
The move settles against the old target first. An event a user created in the
aggregate and that has not yet reached a sink exists only there, and would be
lost the moment we stop looking at that calendar. Only then is every mapped event
rebuilt on the new target — a rewrite rather than a copy, since the rendered
content differs between backends that can and cannot suppress scheduling.
Orphans on the old target are kept unless --purge-old, and a purge is bounded by
the derivation, so events the user keeps in that calendar themselves survive.
Also fixed prepare_vdirs, which created a directory per endpoint. That told
pimsync a local collection existed before its remote counterpart had been seen,
so it tried to create the counterpart: unsupported for a read-only feed, and it
would have invented calendars on a CalDAV server. Only the vdir root is created
now; collections are pimsync's to make from what it discovers.
One test premise was wrong rather than the code: a foreign event in an aggregate
that has a sink is a user-created event and gets adopted into that sink, so it
never reaches a purge as an outsider. Both behaviours are now covered.
Verified against the live Posteo calendar after the change: still a clean no-op.
106 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
