> Really I was thinking of it as a distinct timezone that must be tracked. Whether the DST and non-DST versions label themselves as such, the representation used to track time must distinguish whether DST is active or not to display the correct local time. Really, when I say store local time + timezone, I mean local time plus identifier that gets you to the same unique timezone representation in your medium (python, in this case).
I guess that's my point: the IANA identifier is a well-known way to serialize a TZ, but doesn't include DST flags because they're not relevant. I think if you wanted to store something like a Python tzinfo object, the easiest way is just storing (local time, offset from UTC); (maybe (local time, offset from UTC, IANA TZ ID), if you want to keep the TZ)
tzinfo's don't really have a defining quality in Python, I've found. You can end up — depending on libraries used — with two tzinfos that both conceptually are "UTC", but don't compare equal…
Now that I've thought about it again, I'm not entirely sure that the DST flag + TZ name by itself is sufficient, mostly in the case of a TZ deciding to change their offset.
> just always convert to UTC and store that. It changes the problem from one of data fidelity to display
The right thing to do, and for the right reasons.
