What I've found is that if you save the UTC timestamp + an IANA time zone (e.g. Europe/Paris) you are good. How you convert time for a given IANA time zone at a given UTC time should be consistent. For example in 2024-07-23T10:00:00Z, Europe/Paris should use the offset for the CEST timezone (UTC +02:00 hours).
If at a later point EU gets rid of daylight savings time and France decides to stay on CET year around, date libraries can account for this when you parse the UTC date string and convert it to the provided IANA time zone.
So UTC + IANA time zone gives you an accurate point in local time as long as your date libraries handles IANA time zones correctly.
That's all fine, but the problem case as described in TFA is that if the meeting was scheduled for 9AM (perhaps say 06:00 UTC) before the change, but 9AM now means 07:00 UTC, then you can convert that previously saved timestamp back to local time, but it will still be 8AM, which is not when the meeting was scheduled. The humans all arrive at 9AM (an hour later than originally scheduled with respect to UTC, but correct by the clocks on the wall), the software thinks it started an hour ago.
What I've found is that if you save the UTC timestamp + an IANA time zone (e.g. Europe/Paris) you are good. How you convert time for a given IANA time zone at a given UTC time should be consistent. For example in 2024-07-23T10:00:00Z, Europe/Paris should use the offset for the CEST timezone (UTC +02:00 hours).
If at a later point EU gets rid of daylight savings time and France decides to stay on CET year around, date libraries can account for this when you parse the UTC date string and convert it to the provided IANA time zone.
So UTC + IANA time zone gives you an accurate point in local time as long as your date libraries handles IANA time zones correctly.