Message142150
| Author |
Daniel.O'Connor |
| Recipients |
Daniel.O'Connor, r.david.murray |
| Date |
2011年08月15日.22:57:03 |
| SpamBayes Score |
1.1048308e-08 |
| Marked as misclassified |
No |
| Message-id |
<2D86C48E-8621-49C1-BBE9-82B6009CA31E@dons.net.au> |
| In-reply-to |
<1313422577.83.0.152353179224.issue12750@psf.upfronthosting.co.za> |
| Content |
On 16/08/2011, at 1:06, R. David Murray wrote:
> R. David Murray <rdmurray@bitdance.com> added the comment:
>
> Ah. Well, pre-3.2 datetime itself did not generate *any* non-naive datetimes.
>
> Nor do you need to specify everything for replace. dt.replace(tzinfo=tz) should work just fine.
OK.
I did try this and it seems broken though..
In [19]: now = datetime.datetime.utcnow()
In [21]: now.replace(tzinfo = pytz.utc)
Out[21]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110, tzinfo=<UTC>)
In [22]: datetime.datetime.strftime(now, "%s")
Out[22]: '1313414653'
In [23]: now
Out[23]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110)
[ur 8:22] ~ >date -ujr 1313414653
Mon 15 Aug 2011 13:24:13 UTC
i.e. it appears that replace() applies the TZ offset to a naive datetime object effectively assuming it is local time rather than un-timezoned (which is what the docs imply to me)
> ----------
> resolution: -> invalid
> stage: -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue12750>
> _______________________________________
> |
|