[issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1

[Peter J C Law]

Peter J C Law added the comment:

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

--
Added file: http://bugs.python.org/file38372/time_issues.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23600
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1

[Peter J C Law]

New submission from Peter J C Law:

There's a difference in behaviour between the ``fromutc`` method on a tzinfo 
between Python 2 and Python 3, though only under the specific case of Summer 
Time in regions whose usual offset is 0.

From what I can tell, it's the Python 3 one which is wrong, based on it no 
longer matching the sample implementation provided in the docs and on it 
appearing to report the wrong times for ``datetime.now(tz)`` when on a machine 
configured for BST during June 2015.
Similar results can also be achieved using a manually constructed ``datetime`` 
for dates during summer 2014.

I've put the python script (and sample outputs) I used to investigate in a gist 
at https://gist.github.com/PeterJCLaw/d8bcc168d68acf066811#file-time_issues-py. 
The outputs there are for pythons 2.7.9 and 3.4.0.

--
components: Library (Lib)
messages: 237407
nosy: peterjclaw
priority: normal
severity: normal
status: open
title: tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1
type: behavior
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23600
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com