[Bug]: ICS Event Id's are not stable

[jarofgreen]

Description

When you get an ICS file over time, the Id's should be stable. They aren't.

Steps to reproduce

james@laptop:/tmp$ wget -O 1.ics https://manchester.placecal.org/partners/geeks-for-social-change.ics
--2026-02-19 12:53:50--  https://manchester.placecal.org/partners/geeks-for-social-change.ics
Resolving manchester.placecal.org (manchester.placecal.org)... 46.101.6.200
Connecting to manchester.placecal.org (manchester.placecal.org)|46.101.6.200|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4045 (4.0K) [text/calendar]
Saving to: ‘1.ics’

1.ics                                                                  100%[==========================================================================================================================================================================>]   3.95K  --.-KB/s    in 0s      

2026-02-19 12:53:50 (99.0 MB/s) - ‘1.ics’ saved [4045/4045]

james@laptop:/tmp$ wget -O 2.ics https://manchester.placecal.org/partners/geeks-for-social-change.ics
--2026-02-19 12:53:54--  https://manchester.placecal.org/partners/geeks-for-social-change.ics
Resolving manchester.placecal.org (manchester.placecal.org)... 46.101.6.200
Connecting to manchester.placecal.org (manchester.placecal.org)|46.101.6.200|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4045 (4.0K) [text/calendar]
Saving to: ‘2.ics’

2.ics                                                                  100%[==========================================================================================================================================================================>]   3.95K  --.-KB/s    in 0s      

2026-02-19 12:53:54 (54.9 MB/s) - ‘2.ics’ saved [4045/4045]

james@laptop:/tmp$ diff 1.ics 2.ics 
8,9c8,9
< DTSTAMP:20260219T125351Z
< UID:bdd9e080-1865-4c6d-9725-64f541d308c3
---
> DTSTAMP:20260219T125356Z
> UID:84c25fc0-5771-400d-aedd-cacdbfb9bb0a
23,24c23,24
< DTSTAMP:20260219T125351Z
< UID:1a7ff430-a716-4fc7-8cd8-3b1e2c7300d8
---
> DTSTAMP:20260219T125356Z
> UID:f21a6939-3265-4f41-9866-51a6a057a9c6
39,40c39,40
< DTSTAMP:20260219T125351Z
< UID:a6837b33-fa87-434a-aaec-f7fc240cf223
---
> DTSTAMP:20260219T125356Z
> UID:b4b318b3-c168-462e-8082-7b109e1e6d82
54,55c54,55
< DTSTAMP:20260219T125351Z
< UID:d7e5bed1-aea8-4d76-804f-1f6669413449
---
> DTSTAMP:20260219T125356Z
> UID:487621ac-1244-4d26-baa8-cb5df7ae1871
72,73c72,73
< DTSTAMP:20260219T125351Z
< UID:8aa69090-3eef-4c8f-964c-724e8c6d4425
---
> DTSTAMP:20260219T125356Z
> UID:5b7ee579-140e-485d-a9dc-30f01cda426f

What you expected to happen

UID's should be stable - we should not see UID's change in the diff.

Why this is important

This is important for systems reusing the data - we can't tell whether an "new" event we see in the feed is actually new, or an update to an existing event we've seen before. And if we try to use that UID as some sort of stable ID at our end, that will fail.

Note

I've seen this before in a Ruby system - when I reported it they said the Gem they use for ical will default to random if nothing is specifically set, so maybe it's the same thing here.

[kimadactyl]

this will prob take a bit of digging but i would say the ical endpoint is more designed for individuals to subscribe in their personal calendars - we have the graphql endpoint for more computer-y uses

[jarofgreen]

Personal calendars can be more computer-y uses tho - here's someone trying to add notes and having problems: https://stackoverflow.com/questions/38193837/how-to-handle-a-uid-of-an-ics-calednar-that-will-change-every-time-i-access-it

Here's the spec link: https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.4.7 I think it's good to try and follow the spec as much as possible, as we don't know what clients people may try and use with it. It looks like here the UID's could be in the format "eventid@manchester.placecal.org" - it looks like every occurence of an event in the feed has a unique Id which is used in URL's like https://manchester.placecal.org/events/421333 so there's already an id there.

Good to know about the Graphql end point tho, thanks!