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 acummings
Recipients acummings
Date 2009-03-27.23:23:35
SpamBayes Score 1.2107223e-08
Marked as misclassified No
Message-id <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2009-03-27 23:23:38acummingssetrecipients: + acummings
2009-03-27 23:23:38acummingssetmessageid: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
2009-03-27 23:23:37acummingslinkissue5582 messages
2009-03-27 23:23:35acummingscreate