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 dstufft
Recipients Amber.Yust, Andreas.Pelme, Lakin.Wecker, belopolsky, cvrebert, dstufft, eric.araujo, georg.brandl, gwrtheyrn, lemburg, ncoghlan, pitrou, r.david.murray, shai, tim.peters, yselivanov
Date 2014-03-06.12:12:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394107966.81.0.918623875341.issue13936@psf.upfronthosting.co.za>
In-reply-to
Content
It's actually a bit worse than that Nick. It's midnight UTC, as long as the UTC offset is Positive or Zero. This is because the way the check is implemented is naive.

It's implemented as: Take the time portion sans the tzinfo and convert to minutes, then take the utc offset and convert that to minutes, then subtract the second from the first and if that is zero it is False.

So if you take -5 for instance (my own timezone!) the equation to determine when the "False" time is would look like:

x - (-5 * 60) = 0
x - (-300) = 0
x + 300 = 0
x = -300

So we'd need a time that can be represented as -300 minutes. Since times can not be negative that means for a timezone aware time it is impossible for something with a negative UTC offset to ever be False while for a zero or positive UTC offset it'll be False at UTC midnight.
History
Date User Action Args
2014-03-06 12:12:46dstufftsetrecipients: + dstufft, lemburg, tim.peters, georg.brandl, ncoghlan, belopolsky, pitrou, eric.araujo, r.david.murray, cvrebert, gwrtheyrn, Lakin.Wecker, yselivanov, shai, Andreas.Pelme, Amber.Yust
2014-03-06 12:12:46dstufftsetmessageid: <1394107966.81.0.918623875341.issue13936@psf.upfronthosting.co.za>
2014-03-06 12:12:46dstufftlinkissue13936 messages
2014-03-06 12:12:46dstufftcreate