Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MKCALENDAR does not send valid calendar-timezone #1246

Open
2 tasks done
barkyq opened this issue Jan 16, 2025 · 4 comments · May be fixed by #1251
Open
2 tasks done

MKCALENDAR does not send valid calendar-timezone #1246

barkyq opened this issue Jan 16, 2025 · 4 comments · May be fixed by #1251
Assignees
Labels
bug Something isn't working

Comments

@barkyq
Copy link

barkyq commented Jan 16, 2025

Problem scope

  • I'm sure that this is a DAVx⁵ problem.

App version

  • I'm using the latest available DAVx⁵ version.

Android version and device/firmware type

No response

Steps to reproduce

create a calendar on the davx5 app with caldav server

Actual result

MKCALENDAR /caldav/calendars/c63752c9-37d1-476c-908a-a4f6284570f3/ DAVx5/4.4.5-ose (dav4jvm; okhttp/4.12.0) Android/15

sends this data in the calendar-timezone prop

BEGIN:VCALENDAR
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
TZNAME:UTC+2
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
TZNAME:UTC+1
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

This is not a valid VCALENDAR object as it is missing the mandatory PRODID and VERSION fields.

Expected result

PRODID and VERSION should be added. This is mandated by https://datatracker.ietf.org/doc/html/rfc4791#section-5.2.2

Further info

No response

@barkyq barkyq added the bug Something isn't working label Jan 16, 2025
@ArnyminerZ
Copy link
Member

mandatory PRODID and VERSION fields

Hi, where does it say that they are mandatory for timezones? It's like that on all examples, but it doesn't say it specifically, right?

@barkyq
Copy link
Author

barkyq commented Jan 18, 2025

From the caldav RFC:

<!ELEMENT calendar-timezone (#PCDATA)>
         PCDATA value: an iCalendar object with exactly one VTIMEZONE
               component.

From ICalendar RFC https://datatracker.ietf.org/doc/html/rfc5545#section-3.4

 icalobject = "BEGIN" ":" "VCALENDAR" CRLF
                    icalbody
                    "END" ":" "VCALENDAR" CRLF

The icalbody is defined further down https://datatracker.ietf.org/doc/html/rfc5545#section-3.6

icalbody   = calprops component

       calprops   = *(
                  ;
                  ; The following are REQUIRED,
                  ; but MUST NOT occur more than once.
                  ;
                  prodid / version /
                  ;
                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  calscale / method /
                  ;
                  ; The following are OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  x-prop / iana-prop
                  ;
                  )

Then it says

  An iCalendar object MUST include the "PRODID" and "VERSION" calendar
   properties.  In addition, it MUST include at least one calendar
   component.

@rfc2822
Copy link
Member

rfc2822 commented Jan 18, 2025

Makes sense, and in the example there are both PRODID and VERSION: https://www.rfc-editor.org/rfc/rfc4791#section-5.2.2

May I ask how you found this quite specific issue? Is there a usecase behind it?

@barkyq
Copy link
Author

barkyq commented Jan 18, 2025

I suppose there is no great use case behind it; but davx5 does offer the feature to set the timezone when creating a calendar (used for "floating times").

When I tried to use this feature with my caldav server (the go-webdav implementation), the server reported an error because it could not parse the timezone (the go-ical library is quite strict it seems).

@ArnyminerZ ArnyminerZ linked a pull request Jan 20, 2025 that will close this issue
4 tasks
@ArnyminerZ ArnyminerZ linked a pull request Jan 20, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

3 participants