An event created with Dublin timezone gets mangled after synchronizing with DAVx5

[neko-kai]

I'm synchronizing my calendar with Fastmail CalDAV using DAVx5 on GrapheneOS.
The following event which comes from Fastmail is somehow misinterpreted and being shown as for 11 PM, Feb 3rd, instead of the correct time, which is 2 PM, Feb 4th.
If I create the same event using the London timezone the problem does not manifest.

Related ticket: SimpleMobileTools/Simple-Calendar#1250

BEGIN:VEVENT
UID:5be748aa-01d5-4ae4-0000-0cec2ce08687
SEQUENCE:0
DTSTAMP:20230203T211654Z
CREATED:20230203T211654Z
DTSTART;TZID=Europe/Dublin:20230204T140000
DURATION:PT1H
PRIORITY:0
SUMMARY:Test
STATUS:CONFIRMED
TRANSP:OPAQUE
X-APPLE-DEFAULT-ALARM;VALUE=BOOLEAN:TRUE
END:VEVENT

[rfc2822]

Hi!

I just tried to reproduce the problem and uploaded this iCalendar to our testing Nextcloud, but it was synced correctly…

Can you please provide more details, including the DAVx5 version, the used Android version and which server you have and steps to reproduce? When we would be able to reproduce the problem we could take a look.

[neko-kai]

@rfc2822
DAVx5 4.2.6-ose
Used Android versions: reproduced with 2 different phones with GrapheneOS/Android 13 (versions on screenshot) and on another phone with CalyxOS-2.11.0/Android 11, phones time zone set to Dublin (on screenshot)
Server: https://app.fastmail.com Calendar web app with time zone set to 'Dublin, Ireland'

[rfc2822]

Thanks for the info!

@ArnyminerZ Could you please try to reproduce the problem and create an issue when it's reproducible?

[ArnyminerZ]

I'm trying to reproduce the error on Android 13 in an emulator. Running Simple Calendar Pro 6.21.5, DAVx⁵ 4.2.6-ose. On a Fastmail account. Steps:

1. Create a new event called "Test" for the 4th of February 2023 at 2PM Dublin timezone.

   

2. Run synchronization with DAVx⁵.

3. The generated event is:

   BEGIN:VEVENT
   DTSTAMP:20230207T144226Z
   UID:f48a0653-9365-4a09-a65a-2794a419b67a
   SUMMARY:Test
   DTSTART;TZID=Europe/Dublin:20230204T140000
   DTEND;TZID=Europe/Dublin:20230204T140000
   STATUS:CONFIRMED
   BEGIN:VALARM
   TRIGGER:-PT10M
   ACTION:DISPLAY
   DESCRIPTION:Test
   END:VALARM
   END:VEVENT
   

4. The event displays correctly (14:00 2023-02-04 Dublin) in Simple Calendar Pro.

5. The event displays correctly (15:00 2023-02-04 Vienna) in Fastmail.

@neko-kai can you give more details on the steps you have performed?

[pshirshov]

1. Set the phone timezone to Dublin
2. Open fastmail, select Dublin timezone in the sidebar timezone combobox, then create an event
3. Synchronize fastmail calendar with the phone.
4. Open Simple Calendar Pro or Google Calendar, the event will be offset by minus 11 hours.

We only tested this on GrapheneOS and CalyxOS phones, I'm not sure if it reproduces on AOSP/emulators.

The event in your example looks correct.

If this doesn't help I'll try to record a video later.

[ArnyminerZ]

Okay, finally got it reproduced, quite strange tbh, I'll take a look

[ArnyminerZ]

I'll leave on this thread all the details I gather:

[ArnyminerZ]

I have created an event called "Testing event" for 2023-02-11 at 09:00, the response from the server is correct, this is the response logged by the HttpClient:

<response>
  <href>/dav/calendars/user/xxx@fastmail.com/5f815f69-422f-4101-8f07-152bcaa61b2d/f7552136-265d-4bb5-88a1-79faf08fd6c0.ics</href>
  <propstat>
    <prop>
      <getcontenttype>text/calendar; charset=utf-8; component=VEVENT</getcontenttype>
      <getetag>"093512b76fc41af4defcd115d1bcb2fbaa54f235"</getetag>
      <CAL:calendar-data><![CDATA[BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//CyrusIMAP.org/Cyrus 
3.9.0-alpha0-156-g081acc5ed5-fm-20230206.001-g081acc5e//EN
BEGIN:VTIMEZONE
TZID:Europe/Dublin
LAST-MODIFIED:20221206T194834Z
X-LIC-LOCATION:Europe/Dublin
TZUNTIL:20230211T100000Z
BEGIN:STANDARD
TZNAME:IST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
DTSTART:19961027T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:f7552136-265d-4bb5-88a1-79faf08fd6c0
SEQUENCE:0
DTSTAMP:20230211T142523Z
CREATED:20230211T142523Z
DTSTART;TZID=Europe/Dublin:20230211T090000
DURATION:PT1H
PRIORITY:0
SUMMARY:Testing event
STATUS:CONFIRMED
TRANSP:OPAQUE
X-APPLE-DEFAULT-ALARM;VALUE=BOOLEAN:TRUE
END:VEVENT
END:VCALENDAR
]]></CAL:calendar-data>
    </prop>
    <status>HTTP/1.1 200 OK</status>
  </propstat>
  <propstat>
    <prop>
      <CAL:schedule-tag/>
    </prop>
    <status>HTTP/1.1 404 Not Found</status>
  </propstat>
</response>

But then, when the CalendarSyncManager adds the event to the local calendar, this is what gets logged:

[syncadapter.CalendarSyncManager] Adding f7552136-265d-4bb5-88a1-79faf08fd6c0.ics to local calendar
        PARAMETER #0 = Event=[alarms=[], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=null, dtStart=DTSTART;TZID=Europe/Dublin:20230210T230000
    , duration=DURATION:PT1H
    , exDates=[], exRules=[], exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRules=[], recurrenceId=null, status=STATUS:CONFIRMED
    , summary=Testing event, unknownProperties=[CREATED:20230211T142523Z
    , PRIORITY:0
    , X-APPLE-DEFAULT-ALARM;VALUE=BOOLEAN:TRUE
    ], url=null, sequence=0, uid=f7552136-265d-4bb5-88a1-79faf08fd6c0, userAgents=[]]

Here the timezone is correct (Europe/Dublin), but the time and date have been changed to 20230210T230000 this is 10 hours before.

[ArnyminerZ]

I've run this test:

@Test
fun testDublinTimezone() {
    val e = Event.eventsFromReader(
        StringReader(
            "BEGIN:VCALENDAR\n" +
                    "VERSION:2.0\n" +
                    "BEGIN:VEVENT\n" +
                    "SUMMARY:Test\n" +
                    "DTSTART;TZID=Europe/Dublin:20230211T090000\n" +
                    "END:VEVENT\n" +
                    "END:VCALENDAR"
        )
    ).first()
    assertNotNull(e.dtStart)
    Log.i("ical4android", e.toString())
}

And the timezone is parsed correctly:

I ical4android: Event=[alarms=[], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=null, dtStart=DTSTART;TZID=Europe/Dublin:20230211T090000
I ical4android: , duration=null, exDates=[], exRules=[], exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRules=[], recurrenceId=null, status=null, summary=Test, unknownProperties=[], url=null, sequence=0, uid=04d0576d-aeea-45e7-9085-d61e920f06a9, userAgents=[]]

So the error is not at Event level. I'll try now the whole calendar parse

[ArnyminerZ]

Some tracing information:

The contents appear wrongly in the logcat when printed by CalendarSyncManager:

davx5-ose/app/src/main/java/at/bitfire/davdroid/syncadapter/CalendarSyncManager.kt

Line 179 in 4dd7960

Logger.log.log(Level.INFO, "Adding $fileName to local calendar", event)

Which has been called by CalendarSyncManager.downloadRemote:

davx5-ose/app/src/main/java/at/bitfire/davdroid/syncadapter/CalendarSyncManager.kt

Line 137 in 4dd7960

processVEvent(DavUtils.lastSegmentOfUrl(response.href), eTag, scheduleTag, StringReader(iCal))

The data extraction is performed from the StringReader created by the calendar data of the response, which was correct (as logged before). So somewhere between these two elements, something breaks.

I assume there are no issues with the conversion between the server response data and the XML serializer, since the calendar data is annotated as CDATA, so there are no reasons why the serializer should be breaking anything.

[rfc2822]

Thanks for your testing. Just found https://github.com/bitfireAT/davx5/issues/41 where this is already described.

It's an upstream issue in ical4j: ical4j/ical4j#493

Maybe we could help there

[rfc2822]

@neko-kai A dirty workaround: use the "Europe / Isle of Man" timezone (because it has the same values as the Dublin TZ but works correctly).

Does that work for you?

[pshirshov]

Alright. I still don't understand the scope of the issue.

From what I understood, davx5 uses a java library with a bug.

If the library is fixed, davx5 would work just fine.

The library developers don't care that their library is broken for a whole damn country and haven't paid any attention to the bug in two years.

If that's true, davx5 might work around the issue by monkey-patching the output of the library, using another library or even by setting the system property which is mentioned in that issue.

Why not to do so?

[rfc2822]

I don't like your tone and kindly ask you to be content with the suggested workaround until this is fixed (it is on our list and will be fixed, as noted previously – but it's not a priority issue, measured by how many people have reported the problem).

Or of course you're invited to provide a patch; after all, it's open-source software and as far as I know, we don't have an SLA with you.

This is my final word about this topic. I won't respond anymore and remove further comments if they don't look appropriate.

[pshirshov]

Oh, I'm not trying to press on you or whatever, I'm just trying to confirm if my understanding of the problem is correct and if it is what was preventing the team from fixing the problem.

So, seems like I got the answer - my understanding is correct and the issue is just ignored because it doesn't affect that many users. So, thanks for the confirmation.

It's true that you don't have any SLA for the paying users. I've paid for the app, but I believe I never asked for an urgent solution.
As I pointed before, I'm not pressing, I'm asking.

The proposed workaround is not a workaround because it makes it impossible tn trust the synced events. As I said before, there are some legislative initiatives ongoing and the workaround makes it necessary to closely follow these initiatives. The timezones are different for a reason and the mere fact that two zones are identical at the moment doesn't mean they always would be.

I don't think I said anything offensive or that something was wrong with my tone, but sorry anyways that somehow I got you offended. That wasn't intended.

I might consider submitting a patch, but could you give me a hint where exactly should I look like/which particular calls are broken?

[ArnyminerZ]

I might consider submitting a patch, but could you give me a hint where exactly should I look like/which particular calls are broken?

As stated before, the patch must be addressed by ical4j, you can take a look at the issue here ical4j/ical4j#493

[neko-kai]

@rfc2822
Unfortunately Fastmail doesn't support Isle of Man tz for some unknowable reason - it's in the menu, but selecting it sets the selection to London instead, so this specific workaround doesn't work in this case.

[krillin666]

I have being experiencing the same issue with Timezone Lisbon.

I'm using Nextcloud for the Caldav events and many events that I create either in Nextcloud, Morgen, or Kalendar in my PC get synced to 11pm on my phone through Davx5.

Interestingly, all these wrong timed events on my phone get shown at the correct time in Nextcloud, Morgen, or Kalendar.

[rfc2822]

I can't reproduce that with Nextcloud 25.0.4 and DAVx⁵ 4.3:

1. Create event at 15:15 Europe/Lisbon in Nextcloud.
2. Download the ICS from Nextcloud to verify → DTSTART;TZID=Europe/Lisbon:20230224T151500
3. Sync to Android 12 device (emulator) with DAVx⁵
4. Event is shown at 16:15, which is correct because the device is set to time zone CEST:

Can you please provide more details so that we can reproduce the problem?

[devvv4ever]

I'm synchronizing my calendar with Fastmail CalDAV using DAVx5 on GrapheneOS. The following event which comes from Fastmail is somehow misinterpreted and being shown as for 11 PM, Feb 3rd, instead of the correct time, which is 2 PM, Feb 4th. If I create the same event using the London timezone the problem does not manifest.

Related ticket: SimpleMobileTools/Simple-Calendar#1250

BEGIN:VEVENT
UID:5be748aa-01d5-4ae4-0000-0cec2ce08687
SEQUENCE:0
DTSTAMP:20230203T211654Z
CREATED:20230203T211654Z
DTSTART;TZID=Europe/Dublin:20230204T140000
DURATION:PT1H
PRIORITY:0
SUMMARY:Test
STATUS:CONFIRMED
TRANSP:OPAQUE
X-APPLE-DEFAULT-ALARM;VALUE=BOOLEAN:TRUE
END:VEVENT

The problem with the Dublin timezone has now been workarounded in the library we use and we'll incorporate the fix (which is a bit experimental however) in the next release (4.3.3). It will come in a few weeks. Please check with this version and tell us if it is fixed for your case, too!