BRbrewmarche·Apr 28, 2020
Offset timezones (e.g. UTC+2) don't change, what changes are local timezones (e.g. Europe/Rome).
For example here Turkey decided to change daylight savings time: https://github.com/JodaOrg/joda-time/issues/403 (if you have a look at the tzdata database you will find more, this one I remember because Turkey went back and forth about this).
If your timezone database changes you cannot retrieve the original wall clock time, unless you have a temporal timezone database and remember the date of conversion to UTC.
And if you used offsets instead of local timezones to begin with, you cannot even infer which offsets to change unless you have location data saved as well.
Here is a blog post by Jon Skeet https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... where he says:
> For me, the key difference between the options is that in option
Read the rest
3, we store and never change what the conference organizer entered. The organizer told us that the event would start at the given address in Amsterdam, at 9am on July 10th 2022. That’s what we stored, and that information never needs to change (unless the organizer wants to change it, of course). The UTC value is derived from that “golden” information, but can be re-derived if the context changes – such as when time zone rules change