Webdav calendar messes up timezones with Icewarp - since TZOFFSETFROM TZOFFSETTO from Thunderbird includes optional 00 seconds
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(Not tracked)
People
(Reporter: branislav.klocok, Unassigned)
References
Details
Attachments
(5 files)
Thunderbir_created.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
Create a calendar event in thinderbird (webdav on Icewarp server), restart Thinderbird. Event is moved to different time.
Actual results:
Event is moved to different time.
Expected results:
Event should stay in the same time.
|
Reporter | |
Comment 1•2 years ago
|
||
Maybe a hint, when this event is synchronized to my mobile, I get this error message:
EXCEPTION
at.bitfire.ical4android.InvalidCalendarException: Couldn't parse iCalendar
at at.bitfire.ical4android.ICalendar$Companion.fromReader(ICalendar.kt:161)
at at.bitfire.ical4android.Event$Companion.eventsFromReader(Event.kt:8)
at at.bitfire.ical4android.Event$Companion.eventsFromReader$default(Event.kt:6)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager.processVEvent(CalendarSyncManager.kt:5)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager.access$processVEvent(CalendarSyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1$onResponse$1.invoke(CalendarSyncManager.kt:8)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1$onResponse$1.invoke(CalendarSyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.SyncManager.responseExceptionContext(SyncManager.kt:13)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1.onResponse(CalendarSyncManager.kt:18)
at at.bitfire.dav4jvm.Response$Companion.parse(Response.kt:308)
at at.bitfire.dav4jvm.DavResource.processMultiStatus$parseMultiStatus(DavResource.kt:51)
at at.bitfire.dav4jvm.DavResource.processMultiStatus(DavResource.kt:16)
at at.bitfire.dav4jvm.DavResource.processMultiStatus(DavResource.kt:9)
at at.bitfire.dav4jvm.DavCalendar.multiget(DavCalendar.kt:69)
at at.bitfire.dav4jvm.DavCalendar.multiget$default(DavCalendar.kt:12)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1.invoke(CalendarSyncManager.kt:2)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1.invoke(CalendarSyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.SyncManager.remoteExceptionContext(SyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.SyncManager.remoteExceptionContext(SyncManager.kt:5)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager.downloadRemote(CalendarSyncManager.kt:46)
at at.bitfire.davdroid.syncadapter.SyncManager$syncRemote$1$download$1.invokeSuspend(SyncManager.kt:14)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:112)
at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:163)
at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source:103)
at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source:3)
at at.bitfire.davdroid.syncadapter.SyncManager.syncRemote(SyncManager.kt:39)
at at.bitfire.davdroid.syncadapter.SyncManager$performSync$1.invoke(SyncManager.kt:46)
at at.bitfire.davdroid.syncadapter.SyncManager$performSync$1.invoke(SyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.SyncManager.unwrapExceptions(SyncManager.kt:2)
at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.kt:20)
at at.bitfire.davdroid.syncadapter.CalendarSyncer.sync(CalendarSyncer.kt:175)
at at.bitfire.davdroid.syncadapter.Syncer.onPerformSync(Syncer.kt:168)
at at.bitfire.davdroid.syncadapter.SyncWorker.doWork(SyncWorker.kt:421)
at androidx.work.Worker$1.run(Worker.java:3)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
at java.lang.Thread.run(Thread.java:1012)
Caused by: net.fortuna.ical4j.data.ParserException: Error at line 7:Invalid ID for ZoneOffset, colon not found when expected: +20000
at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:17)
at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:3)
at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:2)
at at.bitfire.ical4android.ICalendar$Companion.fromReader(ICalendar.kt:59)
... 37 more
Caused by: j$.time.DateTimeException: Invalid ID for ZoneOffset, colon not found when expected: +20000
at j$.time.ZoneOffset.parseNumber(Unknown Source:32)
at j$.time.ZoneOffset.of(Unknown Source:95)
at net.fortuna.ical4j.model.property.TzOffsetFrom.setValue(TzOffsetFrom.java:3)
at net.fortuna.ical4j.model.property.TzOffsetFrom.<init>(TzOffsetFrom.java:5)
at net.fortuna.ical4j.model.property.TzOffsetFrom$Factory.createProperty(TzOffsetFrom.java:3)
at net.fortuna.ical4j.model.property.TzOffsetFrom$Factory.createProperty(TzOffsetFrom.java:2)
at net.fortuna.ical4j.model.PropertyBuilder.build(PropertyBuilder.java:43)
at net.fortuna.ical4j.data.DefaultContentHandler.endProperty(DefaultContentHandler.java:24)
at net.fortuna.ical4j.data.CalendarParserImpl$PropertyParser.parse(CalendarParserImpl.java:100)
at net.fortuna.ical4j.data.CalendarParserImpl$PropertyParser.access$1100(CalendarParserImpl.java:1)
at net.fortuna.ical4j.data.CalendarParserImpl$PropertyListParser.parse(CalendarParserImpl.java:47)
at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.parse(CalendarParserImpl.java:37)
at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.access$900(CalendarParserImpl.java:1)
at net.fortuna.ical4j.data.CalendarParserImpl$PropertyListParser.parse(CalendarParserImpl.java:33)
at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.parse(CalendarParserImpl.java:37)
at net.fortuna.ical4j.data.CalendarParserImpl$ComponentParser.access$900(CalendarParserImpl.java:1)
at net.fortuna.ical4j.data.CalendarParserImpl$PropertyListParser.parse(CalendarParserImpl.java:33)
at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendar(CalendarParserImpl.java:29)
at net.fortuna.ical4j.data.CalendarParserImpl.parseCalendarList(CalendarParserImpl.java:15)
at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:13)
... 40 more
LOCAL RESOURCE
Problem is probably here:
Caused by: j$.time.DateTimeException: Invalid ID for ZoneOffset, colon not found when expected: +20000
at j$.time.ZoneOffset.parseNumber(Unknown Source:32)
at j$.time.ZoneOffset.of(Unknown Source:95)
Funny thing is, that when I unclick offline support in this calendar, problem seems to disappear.
|
||
Comment 2•2 years ago
|
||
Can you check with the developer tools what data is sent and received?
|
|
Reporter | |
Comment 3•2 years ago
|
||
|
|
Reporter | |
Comment 4•2 years ago
|
||
|
|
Reporter | |
Comment 5•2 years ago
|
||
|
|
Reporter | |
Comment 6•2 years ago
|
||
|
|
Reporter | |
Comment 7•2 years ago
|
||
|
|
Reporter | |
Comment 8•2 years ago
|
||
I do not know, how can I do that. Can you point me to some "howto"?
Interesting fact is following:
I have created an event in Thunderbird (without offline support): Thunderbir_created.png, as you can see nothing special.
When I looked on day view in calendar it was not there: day_view.png
Funny enough in the week view it was there: week_view.png
I have recheck via webmail interface and it was not there: webmail_view.png
An now the most interesting, my server is sending me reminders and the reminder for this event looks like this: reminder.png
As you can see the time zone the server sees is GMT+20, which is not correct.
|
|
||
Comment 9•2 years ago
|
||
Developer Tools: Ctrl+Shift+I.
|
|
Reporter | |
Comment 10•2 years ago
|
||
One more thing (I will try the developer tools later - need to figure our how to work with them), I have noticed that I have a lot of funny timezones to choose from like systemv/atc4....
|
|
Reporter | |
Comment 11•2 years ago
|
||
So this is the file TB send to server:
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Bratislava
X-TZINFO:Europe/Bratislava[2023c]
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+005744
TZNAME:Europe/Bratislava(STD)
DTSTART:18911001T000000
RDATE:18911001T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19160430T230000
RDATE:19160430T230000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19161001T010000
RDATE:19161001T010000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19170416T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=3MO;UNTIL=19180415T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19170917T030000
RRULE:FREQ=YEARLY;BYMONTH=9;BYDAY=3MO;UNTIL=19180916T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19400401T020000
RDATE:19400401T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19421102T030000
RDATE:19421102T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19430329T020000
RDATE:19430329T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19440403T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1MO;UNTIL=19450402T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19431004T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1MO;UNTIL=19451001T030000
END:STANDARD
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19461006T030000
RDATE:19461006T030000
END:STANDARD
BEGIN:STANDARD
TZOFFSETTO:+000000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(STD)
DTSTART:19461201T030000
RDATE:19461201T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19460506T020000
RDATE:19460506T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+000000
TZNAME:Europe/Bratislava(STD)
DTSTART:19470223T020000
RDATE:19470223T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19470420T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=3SU;UNTIL=19480418T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19490409T020000
RDATE:19490409T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19471005T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU;UNTIL=19491002T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19790401T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=19800406T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19790930T030000
RRULE:FREQ=YEARLY;BYMONTH=9;BYDAY=-1SU;UNTIL=19950924T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:Europe/Bratislava(DST)
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU;UNTIL=19960331T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:Europe/Bratislava(STD)
DTSTART:19961027T030000
RDATE:19961027T030000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:(DST)
DTSTART:19970330T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:(STD)
DTSTART:19971026T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20231009T082226Z
LAST-MODIFIED:20231009T082234Z
DTSTAMP:20231009T082234Z
UID:d9d21c35-744f-4df1-9eba-87917eaa8df4
SUMMARY:Pokus
DTSTART;TZID=Europe/Bratislava:20231009T110000
DTEND;TZID=Europe/Bratislava:20231009T120000
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT15M
DESCRIPTION:Predvolený popis Mozilla
END:VALARM
END:VEVENT
END:VCALENDAR
|
|
Reporter | |
Comment 12•2 years ago
|
||
The problem is in my opinion here:
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
|
|
Reporter | |
Comment 13•2 years ago
|
||
Funny thing, when I check ho the file looks on server I got this:
TZOFFSETFROM:+10000
TZOFFSETTO:+20000
So to mee it seems that TB is putting too many zeros there and then Icewarp is reading and saving it wrong.
|
||
Comment 14•2 years ago
•
|
||
(In reply to Branislav Klocok from comment #13)
Funny thing, when I check ho the file looks on server I got this:
TZOFFSETFROM:+10000
TZOFFSETTO:+20000So to mee it seems that TB is putting too many zeros there and then Icewarp is reading and saving it wrong.
The leading zero is require per specification (see https://www.rfc-editor.org/rfc/rfc5545#section-3.3.14 and https://www.rfc-editor.org/rfc/rfc5545#section-3.3.12). The "00" for the seconds is optional but not against the specification.
|
|
Reporter | |
Comment 15•2 years ago
|
||
What I wanted to say is that TB sends to server this:
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
But Icewarp server writes this:
TZOFFSETFROM:+10000
TZOFFSETTO:+20000
I can only assume that the Icewap has some kind of limit in number of digits and then skips the first 0 or its a matter of formatting and he reads it as number instead of string.
|
|
Reporter | |
Comment 16•2 years ago
|
||
Taking into consideration this error Invalid ID for ZoneOffset, colon not found when expected: +20000 which I get when synchronizing to my phone I tend to think of a formatting issue.
|
|
Reporter | |
Comment 17•2 years ago
|
||
When I tried to write an event to Icewarp via another client (Icewarp web interface) it wrote it like this:
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
So only 4 digits instead of 6.
|
|
Reporter | |
Comment 18•2 years ago
|
||
Same result with creating an event from my phone (Calendar+):
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
Also only 4 digits.
|
|
Reporter | |
Comment 19•2 years ago
|
||
I have talked to Icewarp developers and they have decided to take into consideration also seconds in the time offset settings. This will be done within 2 weeks. Never the less It might be a good option to add some setting to TB, where it can be switched between h:m:s or h:m.
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 20•2 years ago
|
||
It happens also in online mode. I made a premature conclusion before.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 22•2 years ago
|
||
I can confirm the bug. Have the same problem since I've updated from 102 to 115.
My temporary solution is to set the timezone in the Webclient Calendar manually after the synchronisation. Works for now, and only for an small amount of appointments.
|
|
Reporter | |
Comment 23•2 years ago
|
||
Today Icewarp fixed this issue on his side with version 14.0.0.14
|
|
||
Comment 24•2 years ago
|
||
IceWarp changelog mentioning the fix: https://support.icewarp.com/hc/en-us/community/posts/19574741250321-EPOS-Build-14-14-0-0-14-
|
||
Comment 25•2 years ago
|
||
My reading of this bug is that Thunderbird is producing valid iCalendar files per spec, but that Icewarp specifically had an issue in which it could not consume these files. As such, this is not a Thunderbird bug.
If my understanding of this bug is incorrect, please reopen.
|
|
||
Comment 26•2 years ago
|
||
I think that's right. We may still want to exclude the optional seconds for widest compatibility.
I think that's here: https://searchfox.org/comm-central/rev/70240800e172a3ef33ce011f066a51f44fd3a702/calendar/base/modules/Ical.jsm#588
|
|
||
Comment 27•2 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #26)
I think that's right. We may still want to exclude the optional seconds for widest compatibility.
I think that's here: https://searchfox.org/comm-central/rev/70240800e172a3ef33ce011f066a51f44fd3a702/calendar/base/modules/Ical.jsm#588
My guess as to why we see this starting in 115 is that we began using VTIMEZONE definitions sourced from ICU, and that we would have to modify these time zones as we fetched them from the database in order to exclude seconds. I'm reluctant to make that change without evidence of this being a larger issue, particularly given that the known-problematic client has released a production fix.
Description
•