Two-way calendar sync that keeps the edit you have not sent yet

Two-way calendar sync sounds simple: send your changes to Google, fetch Google's changes back. The trouble is the order. Do those two things the wrong way round and a sync can quietly undo the meeting you moved a minute ago, and nobody, including you, would be told.

This post is about how Nemi Calendar keeps a change you have made but not yet sent, why a repeating event is stored as one row and not as a hundred, and the two places where the rules deliberately let the other side win.

How can a calendar sync lose an edit?

Picture a meeting at 10:00 that you drag to 14:00 in Nemi. For a moment the two calendars disagree: Nemi says 14:00 and Google still says 10:00. Now a sync runs. If it reads from Google first, it finds a meeting at 10:00, sees that Nemi's copy is different, and brings it “up to date”. Your move is gone, and when the sync then sends local changes out, there are none left to send.

Nothing about that looks like an error. Every step did what it was written to do. It is the kind of bug that shows up as a client turning up at the wrong time, which is why Nemi's sync is built so it cannot happen. It is the same problem a document editor has with an edit it has not saved yet, with a second party that can change things too. Step through it in the three orders below.

Why does Nemi push before it pulls?

Every change you make in Nemi is saved straight away and marked as not yet sent. A sync of a Google or Outlook account then does two things, always in this order: it sends every marked change out to the provider, and only then reads what the provider has. By the time the read happens, your change is already on the other side, so the read brings back your own version.

The mark is cleared in exactly one place: when the provider has accepted the change. Not when the request was sent, not when the sync finished, only on success. If the push fails, because the provider refused it for a moment or the request never arrived, the change stays marked and is sent again on the next sync. You keep seeing your own version in the meantime, because it is the true one.

The not-yet-sent mark is cleared in exactly one place: when the provider says yes.

Then there is a second rule, for the case the first one cannot cover. When a pull brings in an event that is still marked locally, it refuses to write over it and skips it. So even when a push failed and the read that follows brings back the old time, your change survives until it can be sent. The one thing a pull applies anyway is a deletion or a cancellation made on the other side: a meeting somebody removed is removed here too. The two rules overlap on purpose: either one alone would protect you most of the time, and together they protect you in the order that actually happens.

Is there anything this does not protect?

Yes, and it is a choice rather than an oversight.

Two edits to the same event at once: yours is sent last. Nemi does not ask the provider “has this changed since I last saw it?” before pushing. If you and somebody in Google both move the same meeting before a sync runs, your push goes out first and replaces their version, and the read that follows brings back yours. That is a real trade: the alternative is to stop and ask which version to keep, which is the right answer for documents and the wrong one for a meeting time, where the last deliberate move is usually the one that counts.

How are repeating events stored?

A weekly stand-up that never ends has infinitely many occurrences, so storing each one is not an option. Nemi stores the series the way Google and Outlook describe it: one row holding the first occurrence and a rule, written in the standard calendar format, such as FREQ=WEEKLY;BYDAY=TU. The occurrences are worked out from the rule whenever a week is drawn, and never written down.

Changing one occurrence adds one row, an override, that points at the series and says which occurrence it replaces. Moving next Tuesday's stand-up to 11:00 is an override with the new time. Cancelling it is an override marked cancelled, which leaves a hole in the series, exactly as Google and Outlook express “I deleted this one”. Try it: pick an occurrence and move or cancel it.

Why does the meeting stay at 09:00 when the clocks change?

Every time in Nemi is stored as an exact instant in UTC, so a row means the same moment to everybody who reads it. But a repeating meeting is not a fixed number of hours apart. A weekly stand-up at 09:00 in Amsterdam is 07:00 UTC in October and 08:00 UTC in November, because the clocks go back in between. A rule expanded by adding exactly seven days of milliseconds would put it at 08:00 local time for the whole winter.

So expansion happens on the wall clock of the event's own time zone: the rule produces “Tuesday, 09:00, Amsterdam”, and only then is that turned into an instant. That is why the explorer shows 09:00 on both sides of 25 October while the stored UTC time moves by an hour. That holds for every series, wherever it was made. Outlook hands its times over in UTC, so for a series from Outlook Nemi takes the organiser's own time zone from the event and expands it on that wall clock, the same way.

The expander handles the rules Google's own editor can produce, including “the last Friday of the month” and series that stop after a number of times or on a date. A Google rule with parts it does not use is stored exactly as it arrived and expanded on the parts it understands, so nothing in it is silently dropped. Outlook describes a repeat in its own format, which Nemi translates into a rule; a pattern that cannot be translated becomes a single event rather than a wrong series.

Who can see a connected calendar?

A connected calendar belongs to your account, not to a workspace, so connecting one shows it to nobody else in the workspaces you are in. Nemi asks Google for your name and email address, a read only list of your calendars, and access to calendar events, and it only reads the events in the calendars you enable. The access it is given is encrypted before it is stored; what encrypted at rest means, and what it does not protect, has a post of its own. ICS subscriptions are read only and are never written to. The details are in section 3.7 of the privacy policy.

For connecting an account step by step, see Connecting Google, Outlook and ICS feeds; for repeats and the “this event only” choices, see Events, invitations and repeats. The rest of the app is on the Calendar page.