Hi,
@kavos said in Invalid timezone +005744:
When I create a new event and the event is uploaded up to my CalDAV server (Synology, WebDAV), I can see invalid timezone +005744 in daylight saving section (TZOFFSETFROM:+005744 or TZOFFSETTO:+005744) in the file created on a Synology drive. There were many events like that through years, that behavior is older than v3.0.
TZOFFSETFROM:+005744 is perfectly valid. The problem is that the Synology WebDAV server’s CalDAV function truncates it to TZOFFSETFROM:+5744 (which is invalid), but only on REPORT calendar-query requests (not for GET requests).
The problem is, DAVx5 rejects events with +005744 now. I had to manually edit a lot of files and delete invalid sections.
No, it rejects +5744 (because ical4j rejects that, because Java rejects that, because Java validates the value and it’s invalid).
The only (bad) difference to older DAVx5 versions is that DAVx5 <3.1 parsed TZOFFSETFROM without passing it to Java and thus without validating it, so that invalid value didn’t cause problems for events with DTSTART > 1980 or so.
now I have version 3.1-beta7-gplay released on 22.5.2020 and the problem with timezone is resolved, the timezone info was shortened to one or two basic rules.
Yes, this is a nice side effect of minifying the VTIMEZONE.
The problem in the WebDAV server package remains, see https://www.davx5.com/tested-with/synology#c158. We have reported this to Synology, ticket #2532591.
This problem only appears with the WebDAV server package’s CalDAV function. We strongly recommend to use Synology’s Calendar package instead.