Personally, I just always convert to UTC and store that. It changes the problem from one of data fidelity to display or computation annoyance, and annoyances are easy to reduce or eliminate with tooling.
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.
If you define timezone as an IANA timezone, this is incorrect: a whole slew of local times repeat during a DST fallback event: you'll have a (1:30 AM (dst=True), America/New_York), and then a (1:30 AM (dst=False), America/New_York); that "dst=True|False" bit is the only difference, and that needs to get stored. If you consider "America/New_York" to be the TZ, then storing that bit on the TZ isn't appropriate, as it depends on a particular timestamp.
If you've ever worked with PyTZ, there's a sort of rule of "just call normalize() always"; otherwise, you'll get funny answers to some introspections on the datetime instance: things like the offset being not what a local would say the offset should be. My understanding is that pytz stores the dst flag on the timezone instance itself; things get funny because the timezone instance is not given a chance to update after arithmetic on the datetime instance.
(Really, I feel like the whole thing would work better if there was a separate class for "instant in time" and a function for, "convert this instant in time to Gregorian year/month/day/etc. in this TZ", which then returned a broken-out-type. (And a reverse, of course, for building "Instant" instances.))
UTC datetime + IANA TZ (if relevant) is the way to go. Alas, not all data is so nice.