This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author peterjclaw
Recipients belopolsky, peterjclaw
Date 2015-03-07.11:33:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425727997.55.0.850666894118.issue23600@psf.upfronthosting.co.za>
In-reply-to
Content
Hi,

Sorry for the overkill demo. I've attached a much shorter version, the key portion of which seems to be that, for the case of UK summer time the timezone, the tzinfo's `dst()` and `utcoffset()` methods return the same value.

This results in the delta between the two (which my understanding suggests equates to the non-dst offset of the timezone) is zero (which is right).

The python implementations (both in datetime.py and in the docs) cope with this by checking the DST difference and applying this after the timezone adjustments have happened.

From a look through the CPython implementation, it looks to me like it's checking the wrong value before applying the DST difference. Specifically, on line 3033 in Modules/_datetimemodule.c, it checks `delta` before applying the DST.

For the majority of timezones this happens to work since the standard offset is not 0 and it ends up doing the addition anyway (and no functionality is lost if the DST value is 0).

Having tested changing the checked value to being dst rather than delta this does appear to fix this and all the existing tests still pass.

Peter
History
Date User Action Args
2015-03-07 11:33:17peterjclawsetrecipients: + peterjclaw, belopolsky
2015-03-07 11:33:17peterjclawsetmessageid: <1425727997.55.0.850666894118.issue23600@psf.upfronthosting.co.za>
2015-03-07 11:33:17peterjclawlinkissue23600 messages
2015-03-07 11:33:17peterjclawcreate