I'd say the moral is that server side should always be in UTC.
https://codeofmatt.com/on-the-timing-of-time-zone-changes/
I think the right thing is to store times with the timezone the user wanted when they created the time. You can often use defaults or other UX niceties to streamline specifying TZ, but not always.
Also, if you'll want to unambiguously know the timestamp's exact point in time at some point (like for comparison with other dayetimes), you should save the offset from UTC alongside the actual datetime. Otherwise, around clock changes like "fall back" you cannot tell if you're seeing 2 AM for the first or second time.
This is the best I've come to trying to piece datetime storage together. If someone has better advice, I'd love to hear it.
For more of my theory on timezone handling and the sources I've used to help me think it through, see http://howicode.nateeag.com/dates-and-times.html .
It doesn't solve every conceivable timezone issue, but it solves 99% of the problems most developers would have with it.
Summary:
UT1 - noon is when the sun is above you, day has 86400 seconds (not SI seconds)
TAI - noon drifts away from when the sun is above you, day has 86400 SI seconds
UTC - noon is when the sun is above you (+/- 1 second), day has 86400+/-1 SI seconds
Difference UT1-TAI: continuously diverging
Difference UT1-UTC: continuously diverging up to less than +/-1 second, then discretely jumps back when it gets too big (leap seconds)
Difference TAI-UTC: increasing in discrete increments of +/-1 full second (leap seconds)
Having the length of a second always be the same is kind of important.
[Ed. Nevermind, sorry, I see you're referring to a future point. My bad. You're right.]
For stamping times like in a log though UTC should always be used server side.
Also, I would argue time manipulation is full of many "edge cases" like this one, which is why it's so hard. It's going to work fine until it doesn't.