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.

classification
Title: Incorrect DST transition
Type: behavior Stage: needs patch
Components: Library (Lib), Windows Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: acummings, pitrou, tim.peters
Priority: normal Keywords:

Created on 2009-03-27 23:23 by acummings, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg84286 - (view) Author: (acummings) Date: 2009-03-27 23:23
On Windows, the calculation of when DST starts is incorrect. Windows OS 
seems to be fully patched, and correctly changed to DST on 3-8-2009. 
However, datetime.now() is 1 hour less then Windows displayed time.

I even tried setting the TZ environment variable to 
PST8PDT,M3.2.0,M11.1.0 to fully specify the date change.

Below you can see that today (3-27-08) is marked as standard time, while 
July 1st is DST and Jan 1st is Standard, if I understand the meaning of 
the 9th element of the timetuple:

ON WINDOWS, with windows reporting the time as 3:59pm:
>>> july1 = datetime(2009, 7, 1)
>>> jan1 = datetime(2009, 1, 1)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 3, 27, 14, 59, 46, 4, 86, 0)

It worked correctly on Linux, though: 
>>> july1 = datetime(2009,7,1)
>>> jan1 = datetime(2009,1,1)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 3, 27, 15, 57, 2, 4, 86, 1)
msg94678 - (view) Author: (acummings) Date: 2009-10-29 17:07
The same thing happens with the autumn transition.  Windows knows the 
transition has changed, but python does not seem to know that:

The following interactive session was run on Oct 29th, at 10:02 (Windows 
clock reported 10:02):

>>> july1 = datetime(2009, 7, 1)
>>> jan1 = datetime(2009, 1,1)
>>> oct30 = datetime(2009, 10, 30)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(oct30.timetuple()))
(2009, 10, 30, 0, 0, 0, 4, 303, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 10, 29, 9, 2, 38, 3, 302, 0)

Again, the 9th element of the timetuple is 1 for July 1st, 0 for Jan 
1st, and **0** for Oct 30th and Oct 29th. Also, the time reported by 
datetime.now() was 9:02, one hour behind.
msg94690 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-10-30 00:05
Could you try to confirm with at least Python 2.6? We don't do any bug
fixes on 2.5 anymore.
msg94709 - (view) Author: (acummings) Date: 2009-10-30 15:37
OK, it works correctly on 2.6.4:

>>> time.localtime(time.mktime(datetime(2009, 10, 30).timetuple()))
time.struct_time(tm_year=2009, tm_mon=10, tm_mday=30, tm_hour=0, tm_min=0, 
tm_sec=0, tm_wday=4, tm_yday=303, tm_isdst=1)

I'll close it. Thanks!
History
Date User Action Args
2022-04-11 14:56:47adminsetgithub: 49832
2009-10-30 15:37:32acummingssetstatus: open -> closed

messages: + msg94709
2009-10-30 00:05:06pitrousetpriority: normal

components: + Library (Lib)
versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, - Python 2.5
nosy: + pitrou, tim.peters

messages: + msg94690
stage: needs patch
2009-10-29 17:07:59acummingssetmessages: + msg94678
title: Incorrect DST transition on Windows -> Incorrect DST transition
2009-04-02 21:56:55acummingssettype: behavior
2009-03-27 23:23:37acummingscreate