Logged In: YES 
user_id=56214

But in your use case, if the timezone they attach is in fact
equivalent to localtime, then the conversion would be a
no-op anyway, right?  So how would a conversion in the
general case be wrong?

At the very least, this is a documentation bug.  If these
constructors only produce meaningful results for a tzinfo
that's exactly equivalent to the system's localtime(), then
the docs should say so.  Otherwise, someone can write code
that appears to work, for example, on their own machine, and
then fails when run on a machine with a different concept of
localtime().

Now, if you can actually come up with a sensible use case
for *wrongly* translating a UTC-based timestamp to a
particular timezone, with the degree of wrongness depending
on the difference between localtime() and the specified
timezone, that might justify the constructor behavior.  :) 
As it is, I find it hard to believe that whatever you come
up with will be a more common need than rendering a UTC
timestamp as a datetime value in a specified timezone.