> It is possible to inspect all stdlib functions that use time module and
> determine for some of them whether they will break if gmtime(0) is not
> 1970 or "right" zoneinfo is used or any non-POSIX time encoding is
> used. But it is hard to maintain such a list because any future code
> change may affect the behavior.

Let's not confuse the issue of gmtime(0) not being 1970-01-01T00 and localtime() expecting non-POSIX time_t.  Since gmtime(0) is the same on all platforms supported by Python, it is a fair game to rely on this fact in Python code.

The issue of "right" zoneinfo is different: at least two major Python platforms (OS X and Linux) can be configured in a non-POSIX way.  The decision not to support these configurations in the datetime module was deliberate, but some partial support can be added.  For example, datetime.astimezone() cannot work correctly in the "right" timezone because datetime.second cannot be 60, but if it returns values that are off by some 20 seconds in other times, I would call it a bug, but many will disagree.

I don't know how popular configurations with right timezones are, but testing Python stdlib in those configurations can only help the overall stdlib quality.
(Unfortunately, at the moment we have have very few tests even for the mainstream timezones such as Europe/Moscow.)