I might not be understanding your scenario correctly, but isn't it stated that UTC has 00:00 offset and should be stored that way? You would then add an offset based on current tzdata for that timezone string which would make it dynamic and accurate for the situation you described.
There's two distinct things at play here - storing times in the past and present, and times in the future.
For the past and present, UTC is fine, and a source timezone if necessary. To track the exact instant when something happened to me, just storing UTC is fine. If I want to know what where the hands on my clock were when that happened, you also store which clock I was using separately (timezone), but this is optional and doesn't prevent accuracy.
For future times, relating to humans, like on a calendar, there's a very important distinction - I want to set appointment when my clock shows a certain time, irrespective of what the timezone rules (Daylight saving time rules can change) are at that point. Here, storing the UTC time for my appointment according to today's rules is a problem - you must simply store what I expect to see on the clock and apply the timezone rules lazily at the last possible minute.
