Fix DST arithmetic issues introduced as a side effect of python 3.8 change https://bugs.python.org/issue32417 - #28

…ling

Bring master up to date with upstream, then Improve windows territory handling

Update the j5int fork to the latest master from mithro

….8 changed the datetime arithmetic functions to return instances of the same class as the instance, instead of new datetime.datetime instances.

See the "What's new notes":
Arithmetic operations between subclasses of datetime.date or datetime.datetime and datetime.timedelta objects now return an instance of the subclass, rather than the base class. This also affects the return type of operations whose implementation (directly or indirectly) uses datetime.timedelta arithmetic, such as astimezone(). (Contributed by Paul Ganssle in bpo-32417.)

Unfortunately, the side-effect of this change was to end up calling datetime_tz.__new__ with the set of arguments that result in tzinfo.localize being called on the result instead of tzinfo.normalize. This changed the resulting answer, in particular where DST transitions were involved. The testAroundDst were failing with python 3.8 before this change.

The fix makes it behave in the same way as it did before - where a datetime.datetime object is return from the arithmetic result and then passed to the datetime_tz constructor.

The other functions that do something similar work in the same way (e.g. astimezone).