One important thing to remember is that once a time is in the past, whether or not DST was in effect for that time *is never going to change*. That means converting a DST aware timezone to a fixed offset timezone will work just fine for historical times.

It's mainly applications that need to handle times in the *future* (where the DST dates are still subject to change) that have to be aware of the problems when trying to handle DST with fixed offset timezone objects.

I think it's sufficient if the documentation pushes developers of such applications towards modules like pytz and dateutil to get access to variable offset tzinfo implementations.