Bug 452656

Summary: Unable to upload events to radicale
Product: [Applications] Merkuro Reporter: aunderscored <aunderscored+kde>
Component: generalAssignee: Claudio Cambra <claudio.cambra>
Status: REPORTED ---    
Severity: normal CC: carl
Priority: NOR    
Version: 1.0.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Bug Depends on:    
Bug Blocks: 453052    

Description aunderscored 2022-04-15 11:41:25 UTC
SUMMARY
It would appear that in some cases, the information provided to the calDAV server is invalid, causing it to be rejected.

Specifically, `VTIMEZONE` components missing a required `STANDARD` or `DAYLIGHT` component as noted in RFC5545 (a VTIMEZONE component MUST contain at least one `standardc (STANDARD)` or `daylightc (DAYLIGHT)` component -- https://datatracker.ietf.org/doc/html/rfc5545#section-3.6.5 )


STEPS TO REPRODUCE
1. Start to create a new event on a calendar hosted on a radicale (I'd assume others but havent tested)
2. Set the timezone to Africa/Johannesburg (this is my local timezone -- Obvserved issue with `UTC-10` as well)
3. Save the event

OBSERVED RESULT
```
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VTIMEZONE
TZID:Africa/Johannesburg
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20220415T111224Z
CREATED:20220415T111224Z
UID:84632fb4-6e5e-40ed-9d05-c8192822574a
LAST-MODIFIED:20220415T111224Z
SUMMARY:test four
DTSTART;TZID=Africa/Johannesburg:20220417T131500
DTEND;TZID=Africa/Johannesburg:20220417T141500
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
```

Is sent to the calDAV server, note the invalid VTIMEZONE of:
```
BEGIN:VTIMEZONE
TZID:Africa/Johannesburg
END:VTIMEZONE
```
Where it should include a STANDARD clause indicating its offset

All this ends with is radicale rejecting the invalid event, and thus it not being propagated to things

EXPECTED RESULT
Event is correctly sent to my calDAC server
Comment 1 aunderscored 2022-04-15 11:42:38 UTC
Oh whoops -- forgot to note the tracking issue that I have created on the other side https://github.com/Kozea/Radicale/issues/1236
Comment 2 aunderscored 2022-04-15 12:14:08 UTC
Interestingly, it seems that using `Europe/Berlin` works? I'd assume this is due to that having DST info being included, thus causing it to be populated.