Fix: sync the correct timestamp in repeating event exceptions

[RiccardoCampo]

Type of change(s)

• Bug fix
• Feature / enhancement
• Infrastructure / tooling (CI, build, deps, tests)
• Documentation

What changed and why

• Fixed syncing exceptions to repeating events
• Fixed the original instance time, now using the original event occurrence timestamp

Before & after preview

Closes the following issue(s)

• Closes Singular modification of a recurring event are not synchronized #641

Checklist

• I read the contribution guidelines.
• I manually tested my changes on device/emulator (if applicable).
• I updated the "Unreleased" section in CHANGELOG.md (if applicable).
• All checks are passing.

[naveensingh]

I found two bugs:

1. Converting an all-day instance to a timed event leads to invalid exceptions (duplicates) on the server. You should test your changes, especially when removing any existing logic.
2. Moving an instance from Date A to Date B hides the original Date B instance (this seems to be happening in-app only).

[RiccardoCampo]

I simplified the solution, keeping the existing logic. I was able to move a single occurrence and changing it from all-day to timed event without errors in the emulator (and the event was synced successfully). I wasn't able to reproduce the error you mention in point 2.

[naveensingh]

I was able to move a single occurrence and changing it from all-day to timed event without errors in the emulator (and the event was synced successfully).

There's another bug related to that now. Steps:

1. Create a daily repeating all-day event starting on 2025-09-28.
2. Edit the occurrence on 2025-09-30 and keep it all-day, but change the title.
3. Sync and check server (or other calendar apps). Notice that the occurrence on 2025-09-29 has disappeared due to an incorrect exception, and 2025-09-30 shows duplicates.

You may need to change your timezone to reproduce this. I think we need to drop the !event.getIsAllDay() check and always shift the time when the parent is all-day, but I haven't thought about it, so more investigation will be needed.

I wasn't able to reproduce the error you mention in point 2.

Here are the steps:

1. Create a daily repeating event starting on 2025-09-14.
2. Move the occurrence on 2025-09-17 to 2025-09-18 (change the title to distinguish it).
3. Sync and compare events on the server with Fossify Calendar. You'll notice that there's only one event on 2025-09-18 instead of two (one original and the one we moved from 2025-09-17) in Fossify Calendar.

This will also need more investigation. It's probably a local DB exception that's causing the original instance on 2025-09-18 to disappear.

[RiccardoCampo]

Ok, I was able to reproduce and fix issue number 2 (event occurrence disappearing when another occurrence was moved on the same day). There was a method which did just that (maybeUpdateParentExceptions), I removed it as it was added to fix the single event occurrence moving issue, but it was adding the exception for the wrong timestamp (the edited occurrence TS instead of the original TS).

Still I am unable to reproduce the first issue you mentioned in your last comment, I also set a different TZ on the emulator (and it is also different from the one I have on my calendar)

[naveensingh]

Still I am unable to reproduce the first issue you mentioned in your last comment, I also set a different TZ on the emulator (and it is also different from the one I have on my calendar)

I can still reproduce it in +05:30. To ensure I wasn't seeing things, I also tested with Nextcloud + DAVx⁵, and the occurrence from 2025-09-29 always disappears on the server. Note that in the app, everything looks fine until a sync happens.

[RiccardoCampo]

Ok, I think I fixed it! I was not following your instructions closely, I created the repeating event for just N repetitions, and in that case the error did not show. I did a more torough testing this time 😅

It looks like the original timestamp needs to match the parent being all-day or timed (regardless of the new event form).

I tested these cases:

• all-day event repeading forever:
  • rename one occurrence
  • rename and change to timed event
  • move and rename one occurrence on top of another
• all-day event repeading N times:
  • rename one occurrence
  • rename and change to timed event
  • move and rename one occurrence on top of another
• timed event repeading forever:
  • rename one occurrence
  • rename and change to all-day
  • move and rename one occurrence on top of another
• timed event repeading N times:
  • rename one occurrence
  • rename and change to all-day
  • move and rename one occurrence on top of another

[naveensingh]

I'll check this soon.

Ok, I was able to reproduce and fix issue number 2 (event occurrence disappearing when another occurrence was moved on the same day). There was a method which did just that (maybeUpdateParentExceptions), I removed it as it was added to fix the single event occurrence moving issue, but it was adding the exception for the wrong timestamp (the edited occurrence TS instead of the original TS).

Have you also tested these changes with local events?

[RiccardoCampo]

Have you also tested these changes with local events?

I did not, but I just did now and it works for all cases mentioned above ✅ I also checked for tasks

[naveensingh]

I found one more bug:

Move an instance to some other date ➜ Edit the moved instance again ➜ Refresh ➜ Original instance disappears

[naveensingh]

May the source be with you.