Typically, the best way to contact me with such problems is through opening an issue on GitHub, but I do notice posts here, too. Looking at that excerpt, I fail to see how anything interprets that event as anything other than all day on 2022-09-10. Note the line that reads:
DTSTART;VALUE=DATE:20220910
That pretty clearly indicates the event is to start on 2022-09-10. Is this the wrong excerpt? I also see a lot of custom properties in the event, which is usually a good sign of something that’s non-standard. You can send me the whole ics file privately (with any summaries, descriptions, and locations redacted), and we can work on figuring this out more specifically.
Unless, of course, that really is the correct excerpt. In which case, I can only point to RFC 5545, in particular section 3.6.1, and the last example, which specifically points out that since DTEND as a date is not inclusive, in your excerpt above with DTEND set to 20220911, that the event ends on 2022-09-10.
Thanks for your reply and sorry for not having opened an issue on GitHub!
I’ve started another test with an empty calendar.
Here is the complete ics file:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Kopano//11.0.2//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
TRANSP:TRANSPARENT
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
CREATED:20220908T213511Z
LAST-MODIFIED:20220908T213511Z
DTSTAMP:20220908T213511Z
DTSTART;VALUE=DATE:20220911
DTEND;VALUE=DATE:20220912
SUMMARY:appointment test 2022-09-12\, all day
PRIORITY:5
CLASS:PUBLIC
UID:
040000008200E00074C5B7101A82E00800000000800564E4CAC3D801000000000000000001
00000035A1B8102AFD4AE9AC9D0C575AFC4F57
X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20220908T213519Z
X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20220908T213519Z
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
END:VEVENT
END:VCALENDAR
The all day event was created with Kopano WebApp for 2022/09/12 and is correctly shown there.
It is also correctly synchronized to my iPhone via z-push / ActiveSync.
I can confirm that all timezones (Debian / MariaDB / z-push / Kopano) are properly set to “Europe/Berlin”.
Thanks for the reply, and the more information. As earlier, that ICS file clearly indicates the start date of the event is 2022/09/11, not 2022/09/12. If you’re viewing it on your iPhone via z-push/ActiveSync, then my guess is that Kopano doesn’t natively store the data in ICS format. ActiveSync doesn’t use ICS to exchange data, so if it’s right on your server, then it makes sense that anything which gets the data via ActiveSync will also be correct. I think Kopano has a bug when it generates the ICS file. In a quick look, I do see some references to Kopano & CalDAV. Normally, I recommend using CalDAV because it’s more efficient (and moves most of the work onto the server). In this case, though, it’s important to note that CalDAV does use ICS, so the chances are that it wouldn’t help. If you can report the problem, and want somebody who can reference the RFCs to say that what was produced is wrong, I’d be happy to do that. I’m sorry I can’t fix the issue, though.
Your explanation seems absolutely sensible to me.
There is a Kopano community forum where I’ve opened a thread: Kopano Community Forum
There is also a plugin called “Kopano kDAV” (kDAV) that is based on SabreDAV and adds CalDAV and CardDAV to Kopano. I’ve already installed it, but that strange behaviour also happens with kDAV and not only with the iCal interface that is built-in into Kopano server…
Unfortunately, I didn’t get any response to my Kopano GitHub issues until today.
But I made an interesting observation:
I recently set up a Univention server (open source) which also contains a free Kopano Groupware setup in its AppStore that does not show the observed ical bug.
I compared the Kopano settings to those of my “hand-built” server and couldn’t find any differences concerning configuration or timezone settings. Still, the Kopano version offered by Univention is older than the one I got from the Kopano community sources.
As nobody related to Kopano was willing to answer my requests, I decided to switch to the Univention platform. I will move my AD controller and my email server to that one in the next days and have another test run afterwards.
I will report my findings when it’s finished. Tom, thanks for your kind support concerning this issue!
Is there a way to import an ICS calendar into an existing google calendar rather than creating a new calendar?
I use an ICS calendar provided by my work scheduling tool for my shifts. My issue is that the events imported from the ICS calendar aren’t kept once “today” passes. My ICS calendar provides shift schedules for 3 weeks in adavance from this weeks current Monday. When the ICS calendar rolls over to next Monday and the ICS calendar is updated then the past weeks shift schedules are no longer displayed on the calendar. Hopefully that makes sense.
I’d like to import the ICS calendar to allow them to be static ie. still exist after the ICS calendar has been updated.
Hopefully this post can save someone the time it took me to figure this out.
To get the link for a Family Wall calendar, open the calendar page, and on the right side of the screen, click the arrow on the right side of the calendar you want to add. That will let you create a sharing link. It’s an iCal file, so you’ll need to add the iCal integration not the ics one.
(I changed the URL for more privacy, so the URL is not working in this example here.)
I have two questions:
a.) I use the calendar card, and wonder, why I see the full calendar and not only the actual day. as I though “days: 1” shows only one day.
b.) At the end, I want to transfer the ONE calendar day to my ESP32 ePaper and show it on the ePaper.
My idea is to ready make a text sensor with all the data, that I than can transfer to the ESP.
Looking at that excerpt, I fail to see how anything interprets that event as anything other than all day on 2022-09-10. Note the line that reads:
In a quick look, I do see some references to Kopano & CalDAV. Normally, I recommend using CalDAV because it’s more efficient (and moves most of the work onto the server). In this case, though, it’s important to note that CalDAV does use ICS, so the chances are that it wouldn’t help. If you can report the problem, and want somebody who can reference the RFCs to say that what was produced is wrong, I’d be happy to do that. I’m sorry I can’t fix the issue, though.