Paul Ganssle

> Unfortunately, I've found the `tzinfo` insufficient to perform even simple tasks, like "given a tz-naive datetime `d` and a timezone `tz`, apply `tz` to `d`" with consistent semantics across...

`datetime_exists `, `datetime_ambiguous` and `resolve_ambiguous` work with all standard time zone providers. They may work with `pytz`, I'm not sure.

I think there's no compelling reason here to add support for this, so I'm going to close the issue. We can always re-open it if someone presents a compelling reason.

This seems to be related to how they packaged `dateutil`. Presumably it's pulling in a version of `setuptools_scm` that doesn't work on Python 2.

Can you make a much more minimal example of this? What is the smallest amount of code that exhibits the unexpected behavior, and what is the behavior you are expecting...

Hmm... > ```diff > + sphinx/builders/gettext.py: note: In member "dst" of class "LocalTimeZone": > + sphinx/builders/gettext.py:192:5: error: Signature of "dst" incompatible with supertype "tzinfo" [override] > + sphinx/builders/gettext.py:192:5: note: Superclass:...

> If a superclass says that it will accept a `datetime.time` for a parameter in some circumstances, but a subclass says that it doesn't accept a `datetime.time` under any circumstances...

I don't think it needs to block this particular PR, but is the subinterpreter work advanced enough that we can add an actual test that the module isolation worked yet?...

> This issue is open for 2 years. Sounds like it's not very urgent, then. Seriously, Victor, I appreciate the work you've put in on this, but I don't appreciate...

> I don't think modifying the signature of builtin methods is a good idea since we can't know if they will change in future Python versions. @sdispater The [the signature...