Simple-Calendar
Simple-Calendar copied to clipboard
SimpleMobileTools
[Bug] Incorrect time(s) for recurring UTC event
(funny, GitHub won't let me upload an ICS file …)
The first event (starting) in 2022-02, call it february.ics.
BEGIN:VCALENDAR
PRODID:icsbugs.example.org
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Some event with bugs
RRULE:FREQ=WEEKLY;INTERVAL=2
DTSTART:20220205T180000Z
DTEND:20220205T190000Z
END:VEVENT
END:VCALENDAR
The second event (starting) in 2022-04, call it april.ics (same as above with month changed).
BEGIN:VCALENDAR
PRODID:icsbugs.example.org
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Some event with bugs
RRULE:FREQ=WEEKLY;INTERVAL=2
DTSTART:20220405T180000Z
DTEND:20220405T190000Z
END:VEVENT
END:VCALENDAR
Since DSTART is in UTC (also see RFC 5545 section DATE-TIME FORM #2, page 34) one would expect the event "survives" Daylight saving time changes in the users time zone. As a result, the (initial) date of such an event should not matter, i.e. every future recurrence starts at 1800 UTC.
That is not the case currently. At the moment (2023-02-09) february.ics events correctly start at 1800 UTC (resp. my local time) whereas april.ics events incorrectly start at 1900 UTC (rep. my local time). (In other words: the event time is constant against the users local time zone no matter DST or not.)
Also when going forward in the calender to sometime 2023-04 (after Daylight saving time switch) the times stay the same although one would expect them to change since time zone changed (and time is UTC).
I can confirm that is happening here, too. Same repeating calendar entry (added during CEST) shows up 8 pm with Simple Calendar (incorrectly) while showing up 7 pm with Etar on the very same device from the very same source (synced to the device from Nextcloud via DAVx⁵).
The app (no longer) respects timezones? A ton of my recurring events happen at UTC/GMT and I'm not in that timezone. Notifications seem allright (samsung/android 12), but the displaying in the calendar view is wrong. I don't do stuff at 2AM...
When I switch to the default Samsung calendar app it all works fine again. Just not in your app. These same events, synced via nextcloud, work fine on macOS and iOS calendar apps.
I have the same problem but for a simple non-recurring event. this is on Simple Calendar Pro. And this is a show stopper, I am glad it brings me 1 hour early and not 1 hour late this time.
I am in Stockholm. The event is in London.
Thunderbird imports it properly, Simple Calendar Pro does not:
BEGIN:VCALENDAR
PRODID:-//zoom.us//iCalendar Event//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/London
LAST-MODIFIED:20230104T023643Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZNAME:BST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
DTSTART:19700329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20230320T155151Z
DTSTART;TZID=Europe/London:20230323T170000
DTEND;TZID=Europe/London:20230323T180000
SUMMARY:My Summary
UID:b97kuj9o6ksj8cph6go3ic1mf8q7kthn8l662kjmd5okoh9odl3neo9p91rg
TZID:Europe/London
DESCRIPTION: my description
LOCATION:my location
ORGANIZER;ROLE=REQ-PARTICIPANT;CN=blahblah Webinars:[email protected]
ATTENDEE;ROLE=REQ-PARTICIPANT;CN=First Last:[email protected]
BEGIN:VALARM
TRIGGER:-PT10M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
@Tridy "I am glad it brings me 1 hour early and not 1 hour late this time." As far as I can tell the notifications will be on time. But the events will show the wrong stuff.
I think this basically means that the app ignores or neglects timezone support. But until the devs fix it it'll be a dealbreaker none-the-less.
@adegans Thanks for the info. Well, I do not want to take my chances. There are some alternative calendar apps but I kind of got used to SCP. Let's hope they will fix it soon.
@adegans Thanks for the info. Well, I do not want to take my chances. There are some alternative calendar apps but I kind of got used to SCP. Let's hope they will fix it soon.
Yep I switched to Samsungs standard app for the time being - I hate seeing wrong times... I don;t think the devs care too much to fix this either, since this issue has been open and lingering unanswered since feb 9 🙄
I will go back to One Calendar for now (onecalendar.nl). It looks like I have used it before. I guess I will figure out soon why I switched to SCP.
This also occurs for events created with Simple Calendar, so if I create an event after local daylight savings time starts with a timezone that does not shift at the same time, after opening the event edit screen again it will show a different time than the one I entered.
Okay, I figured out what's going on: When creating a recurring event spanning a local DST change with Simple Calendar, it gets created with the right timezone and time but displayed the wrong way after the change in both over- and edit view. That wrong display we were already aware of. But if one creates an event (specifically the first one in the case of a recurring event) past the local DST change it will be created with the wrong time, but displayed correctly. So anyone who has created events in other timezones set in the future should double check them, as fixing the display bug will not change the wrong time the event might have. This also makes it critical that the bug be fixed soon, because it will continue to wreak lasting havoc in people's calendars while it exists.
Simple Calendar is incorrectly storing certain events (not only recurring)
My observations so far:
(Environment: PhoneTZ=UTC, EventTZ=Europe/Berlin) (CET=winter time, CEST=summer time) (ics used in testing: timezone-tests-1-2023-03-27.ics.txt)
- 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)
- An event that's created while being in CET, is incorrectly displayed once in CEST (ics file has incorrect DTSTART/DTEND time). This is very dangerous as it'll even show with the incorrect time in different apps, as the event itself is incorrectly stored.
As mentioned by @citriqa one needs to double check each entry created during winter time (CET) as they are probably incorrectly stored when they occur during summer time (CEST).
Especially the last case point of data being stored incorrectly needs fixing ASAP @tibbi . In my case it shows/stores meetings as 1h later than the should be, which is quite dangerous.
Details & Images
One can see how Events created by Nextcloud(NC) and by Simple Calendar Pro (SCP) during CET are not moved appropriately. E.g. NC/CET - 6 Europe/Berlin - 7 Europe/Berlin should move from 5:00 to 4:00 on Sunday
NC and SCP/CET still not moved appropriately but most importantly Important Meeting is not at 10 meaning (given UTC+2 during CEST) it's shown for 12 AND stored incorrectly (DTSTART;TZID=Europe/Berlin:20230328T120000) as well.
That said while better, Etar seems to not handle all cases perfectly either:
On the day of the switch it mixes up the end time of the 1-4 event adding a ghost hour until 3 instead of 2.
And messing up all(?) reoccuring events stored as 2-3 with start-date in CET for CEST events (1-2 instead of 0-1). But I haven't really tested here much as SCP was my main focus.
(To create the SCP/CET - 11 Europe/Berlin - Important meeting (Created during CET for CEST) I have set my phones date back to 20.03.2023 forcequit the app, reopened it, created the event, synched, force quit app, reset time to normal, opened app. I believe I can discard blaming the sync as I had this happen with real events that I had planned for the coming months)
Same for me. I'm syncing with Nextcloud using DAVx5, and got a recurring event created in the MSK timezone. I'm living in CET/CEST now.
End result: missed my call by an hour because SCP doesn't do the conversion correctly if the recurring event falls on DST change at the remote end. Whoops. Guess I'll need to use a different app for the time being...
