Changes to the order of VTIMEZONE components in an .ics file cause sync conflicts against calDAV

Hi,

I mentioned this on IRC chat and it was suggested I raise an issue. I've got a local ics file (type=singlefile) that recently starting conflicting against the server (type=caldav) for every item. It looks like my calendar app (Evolution/GNOME) changed the order (but not the content) of all the VTIMEZONE entries in the .ics file.

I've never seen this before in many years of using vdirsyncer and Evolution. My guess is a recent change in how Evolution orders timezones when it writes to file probably triggered the conflicts for vdirsyncer.

vdirsyncer version: 0.18.0

Config:

[general]
status_path = "~/.var/app/vdirsyncer/status/"

[pair my_calendar]
a = "my_calendar_local"
b = "my_calendar_remote"
collections = ["from a", "from b"]

[storage my_calendar_local]
type = "singlefile"
path = "~/Calendar/%s.ics"

[storage my_calendar_remote]
type = "caldav"
url = "XXX"
username = XXX
password.fetch = XXX

The .ics file used to start like this when there were no conflicts (just showing the first timezone entry):

BEGIN:VCALENDAR
VERSION:2.0
PRODID:Data::ICal 0.22
X-EVOLUTION-DATA-REVISION:2023-08-31T13:35:36.222653Z(2)
X-EVOLUTION-DATA-REVISION:2020-04-17T09:40:26.052724Z(2)
...
BEGIN:VTIMEZONE
TZID:America/Denver
BEGIN:STANDARD
DTSTART:20221106T010000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20220313T030000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
END:DAYLIGHT
END:VTIMEZONE
...

Then it changed to start like this and now every item causes a conflict in vdircyncer:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:Data::ICal 0.22
X-EVOLUTION-DATA-REVISION:2023-09-19T12:16:45.228325Z(7)
X-EVOLUTION-DATA-REVISION:2020-04-17T09:40:26.052724Z(2)
...
BEGIN:VTIMEZONE
TZID:America/New_York
TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
END:VTIMEZONE
...

I tried manual conflict resolution with a diffing tool and I could see that if I rearranged the VTIMEZONE components I could get the files to match exactly. So all that has changed in my .ics file is the ordering I believe.

Hopefully if vdirsyncer could just sort the timezones or something these differences could be ignored/auto-resolved. Thanks for any help!

Reproduce the conflict with the provided singlefile and caldav configuration, focusing on the .ics VTIMEZONE component order. Compare the local and remote calendar data when timezone content is unchanged but reordered. Done means order-only VTIMEZONE changes no longer create conflicts or are auto-resolved.