Invalid timezone +005744

DAVx⁵
Log in to reply
  • K

    Hello, I have a problem with calendar events, maybe from version 3.0 (it started a week or two ago).

    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.

    The problem is, DAVx5 rejects events with +005744 now. I had to manually edit a lot of files and delete invalid sections.

    As a calendar app I use aCalendar (Tapir Apps GmbH), but timezone +005744 is added with uploading an event by DAVx5 – when I share an event from aCalendar to an email[0_1589277394682_event.ics](Uploading 0%) , it has no daylight saving section, but on the Synology drive it has one or more. See both files attached (oops, uploading doesn’t work for me now, I’ll paste the invalid section below).

    Sony Xperia XZ1 Compact (G8441), Android 9

    Thanks for help
    Zdeněk Kavalír

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:+//IDN bitfire.at//DAVx5/3.1-beta3-gplay ical4j/3.0.18
    BEGIN:VEVENT
    …
    BEGIN:STANDARD
    TZOFFSETFROM:+005744
    TZOFFSETTO:+005744
    TZNAME:PMT
    DTSTART:18500101T000000
    RDATE:18500101T000000
    END:STANDARD
    BEGIN:STANDARD
    TZOFFSETFROM:+005744
    TZOFFSETTO:+0100
    TZNAME:CET
    DTSTART:18911001T000000
    RDATE:18911001T000000
    END:STANDARD

    K R 2 Replies 0
  • K

    Hello,

    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.

    Thanks a lot,
    Zdeněk Kavalír

    0
  • R
    developer

    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.

    1
  • R
    developer

    Until this is fixed in the server, we have added a workaround which is shipped with DAVx5 3.1-rc1 (latest beta on Google Play). Does it work for you with 3.1-rc1 again?

    0

Similar topics