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.