Logged In: YES 
user_id=31435

I think Guido has more energy for this than I have (I'm 
pretty much burned out on this module), so assigned it to 
him.

At the time fromtimestamp() was added, there wasn't any 
reasonable way to simply attach a tzinfo object to a 
datetimetz.  About the best you could do is

new = datetimetz(old.year, old.month, old.day, old.hour, 
old.minute, old.second, old.microsecond, tzinfo)

So the use case of *simply* getting a local datetimetz out 
of a timestamp was quite a pain.  
datetimetz.fromtimestamp grew an optional tzinfo arg to 
ease that pain.

There was no notion of timezone conversion at that time 
either, so of course none of the methods were intended to 
do any sort of conversion.  Note that the primary 
constructor-- datetimetz --also takes all of its arguments as 
being in local time.  It would strike me as inconsistent if 
fromtimestamp() didn't also take its argument as being in 
local time.

Things changed since then, and I at least agree the docs 
should be clarified.  But rather than make the constructors 
even more complicated, I'd rather drop the optional tzinfo 
arguments from fromtimestamp() and now().  There are at 
least two easy ways to attach a tzinfo tz to a datetimetz 
now:

new = old.astimezone(tz)  # no conversion if old was naive
new = old.replace(tzinfo=tz) # no conversion ever

and there's also an explict time zone conversion method.