Wrong event times

[sunkup]

Thunderbird (and apparently other calendar software) imports the event in the following calendar (see details) as happening at 16:30, while ICSx5 imports it at 01:00 am (same day).

Until now all reported ics files have been generated by the Wordpress events plugin.

Discussed in #188

Depends on ical4j/ical4j#651

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//wp-events-plugin.com//6.5.2//EN
TZID:Europe/Berlin
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VEVENT
UID:583@dokus.uni-stuttgart.de
DTSTART;TZID=Europe/Berlin:20240925T163000
DTEND;TZID=Europe/Berlin:20240925T180000
DTSTAMP:20240910T154945Z
URL:https://dokus.uni-stuttgart.de/events/dokus-sitzung-2024-09-24/
SUMMARY:DoKUS-Sitzung
DESCRIPTION:Die DoKUS-Sitzung
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
DTSTART:20240331T030000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20241027T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20250330T030000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20251026T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20260329T030000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
END:VCALENDAR

[ArnyminerZ]

I think, as far as I can remember, that we couldn't do much, it had to be fixed by WEM (edit: or at least ical4j)

[sunkup]

Correct. Unfortunately we are on the final release of ical4j and won't be able to update to 4.x.x without a lot of work - not to mention DAVx5 would have to get updated at the same time, unless we create a separate branch in ical4android.

I wanted to check whether the issue also occurs with ical4j 4.0.4.

[ArnyminerZ]

I wanted to check whether the issue also occurs with ical4j 4.0.4.

We can try on 4.0.4 using the test I made for ical4j/ical4j#651, I think it shouldn't be too much. Though yes, migration to ical4j 4.x will be a big thing. Without thinking much into it, are really DAVx⁵ and ICSx⁵ going to be affected if we upgrade and migrate to ical4j in ical4android? I mean, maybe return types on some places will be changed to the new ones, but we can really keep the old syntax, with the old types, and deprecate those methods in favor of the new ones. It will be a bit more work (though I don't think that much), and will make migration in the apps really easier, since if we take the time to add proper ReplaceWith attributes, pretty much everything could be done automatically through the IDE.

Again, I haven't really looked at it since a lot of time ago, but I don't see why we couldn't.

[sunkup]

We can try on 4.0.4 using the test I made for ical4j/ical4j#651, I think it shouldn't be too much.

Your test does not fail anymore. Not sure why, but maybe because we are in daylight saving time now? I tried with another example from the discussion which still fails in ical4j 3.2.19 and got a parse exception with ical4j 4.0.4 ical4j/ical4j#651 (comment) .

[sunkup]

Will probably not be able to solve this within the next version.

[github-actions]

This PR/issue depends on:

• Time of Event not correct with Events from Wordpress Events Manager ical4j/ical4j#651

[q-wertz]

I don't really know why, but the times are now correct in my phones calendar...
Cannot really see a change in Wordpress Events Manager and I also think there was no new ICSx5 version.
Just noticed yesterday, that the events have the correct time...

Some time ago I changed this setting in Events Manager to "No" but didn't see any improvement. Maybe it just took some time for sync?

On the other hand side the current ics

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//wp-events-plugin.com//6.6.1//EN
TZID:Europe/Berlin
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VEVENT
UID:776@dokus.uni-stuttgart.de
DTSTART;TZID=Europe/Berlin:20241022T163000
DTEND;TZID=Europe/Berlin:20241022T180000
DTSTAMP:20241008T183142Z
URL:https://dokus.uni-stuttgart.de/events/dokus-sitzung-2024-10-29/
SUMMARY:DoKUS-Sitzung
CATEGORIES:DoKUS-Sitzung
END:VEVENT
[...]

looks the same way to me as reported earlier