mithro / python-datetime-tz / 112 / 1
89%
master: 89%

LAST BUILD BRANCH: py38
DEFAULT BRANCH: master
Ran
Files 5
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 88.567%. Remained the same
112.1

Pull #28

travis-ci-com

web-flow 
Changes introduced in https://bugs.python.org/issue32417 for python 3.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).
Pull Request #28: Fix DST arithmetic issues introduced as a side effect of python 3.8 change https://bugs.python.org/issue32417

550 of 621 relevant lines covered (88.57%)

0.89 hits per line

Source Files on job 112.1