Incorrect handling of DST for reoccurring events

[freezingDaniel]

Checklist

• [X] I can reproduce the bug with the latest version given here.
• [X] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• [X] I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• [X] I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• [X] This issue contains only one bug.
• [X] I have read and understood the contribution guidelines.

Affected app version

1.0.2

Affected Android/Custom ROM version

Android 13&14

Affected device model

Tab S6 Lite

How did you install the app?

F-Droid / IzzyOnDroid

Steps to reproduce the bug

1. Set Device TZ/clock to UTC+0
2. Set Device Date to 2024-03-25 (not sure if necessary)
3. Calendar settings: Events>Allow chaing event time zones
4. Create Events
   1. Create daily reoccuring event for 3 days at 2am & 3am with Timezone Berlin from 2024-03-30 to 2024-04-01
   2. (optional) repeat with different calendar app

Expected behavior

On 2023-03-26 in the morning in Germany (at 2am German/eventTZ) the clock is set to an hour forward to (to 3am) DST

• 2024-03-30 events stay the same
• 2024-03-31 events (2am&3am) should overlap
• 2024-04-01 events should be moved accordingly

Samsung Calendar:

Actual behavior

• events are shown incorrectly

Screenshots/Screen recordings

see above

Additional information

It has been a while since I originally encountered this issue (by missing an important appointment) but it is the reason why I had to stop using this Calendar.

While I have not verified this time, for my old issue I came to the conclusion:

• A recurring event that's created while being in CET, is incorrectly displayed once in CEST (ics file is correct)
• A recurring event that's created while being in CEST, is correctly displayed in CEST (ics file is correct)

Maybe related to: Issue-166

Potentially useful in case I missed something: https://github.com/SimpleMobileTools/Simple-Calendar/issues/1973

[naveensingh]

I was able to reproduce this issue and #166 with the latest version (after a couple of tries).

It seems to me that in this case, the events are saved properly but are displayed incorrectly whereas in #165 the events are not saved with the correct start and end time.

[aaa-cubed]

This bug (or something very similar) is still occurring with version 1.03, following the autumn time change. Events from my synced Google Calendar, created by an external party, with a time in CEST for a repeat continuing through the autumn shift back one hour, are shown as occurring one hour too early in the FOSSIFY Calendar on a phone set to JST (which does not have a daylight savings change). The in-built Samsung Calendar app and the Google web calendar shows them correctly shifted to one hour later.

[davidlove]

Still occurring in 1.1.0. Just missed my kid's ballet class because it was listed in the calendar as an hour later than reality.

We're in the Phoenix time zone, which doesn't follow daylight saving time, but all times shifted an hour later.

ETA: the time of every event in the series shifted, not just the ones after daylight saving time. Back in October, the calendar showed all events as occurring weekly from 3 to 4. But now the calendar shows all events in the series as 4 to 5.

I'm using Etesync to store the caldav, it shows the raw event info, including

DTSTART;TZID=America/Phoenix:20241021T150000

But the event starts at 4 in the displayed calendar.

[tom93]

Debugging notes:

I can reproduce this using the steps (I didn't need to set the device date).

It looks like the code is plain wrong -- it uses the default (device) time zone in many places, ignoring the event's time zone.

It would probably take some serious effort to fix this everywhere. In the meantime, I'd personally treat the per-event time zone features as broken and avoid using it.

[Fmstrat]

It would probably take some serious effort to fix this everywhere. In the meantime, I'd personally treat the per-event time zone features as broken and avoid using it.

Any idea if any work will be done against this? A calendar app should probably prioritize appointment times being correct ;) Just ran into similar in the above linked issue with DST. I wish I had the time to dive into another project to take a look.

[naveensingh]

Any idea if any work will be done against this?

Yes but there's no precise ETA :)

May get fixed before the next update or the update after that.

[Fmstrat]

Yes but there's no precise ETA :)

May get fixed before the next update or the update after that.

Amazing, thank you. Started to skim but quickly realized i wouldnt have time for a PR with my other commitments.