Author r.david.murray
Recipients ajaksu2, akuchling, barry, belopolsky, brett.cannon, doerwalter, merwok, python-dev, r.david.murray, tim.peters
Date 2012-06-23.15:00:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340463606.12.0.175701196356.issue665194@psf.upfronthosting.co.za>
In-reply-to
Content
Well, I guess I'd like to keep it since it does satisfy a need in the email package: to manipulate dates in the local timezone when composing messages.  It isn't a critical need, though; the critical need is just to be able to have a datetime that has the correct timezone as its tzinfo for 'now', and your astimezone change supplies that.  On the third hand, 'util.localtime()' is a lot more intuitive then 'datetime.now().astimezone()', so I'd probably still have a util.localtime() helper even if I restricted it to only generating 'now'.

So, on balance, since the method is in and tested with the extra functionality, and that functionality will probably prove useful to programs manipulating emails, I'm coming down in favor of keeping it.
History
Date User Action Args
2012-06-23 15:00:06r.david.murraysetrecipients: + r.david.murray, tim.peters, barry, akuchling, doerwalter, brett.cannon, belopolsky, ajaksu2, merwok, python-dev
2012-06-23 15:00:06r.david.murraysetmessageid: <1340463606.12.0.175701196356.issue665194@psf.upfronthosting.co.za>
2012-06-23 15:00:05r.david.murraylinkissue665194 messages
2012-06-23 15:00:05r.david.murraycreate