datetimetz.fromtimestamp(timestamp,tzinfo) creates a
datetime which has the localtime() value of timestamp,
with the tzinfo attached as its timezone.  But this
produces a counterintuitive result.  Instead of getting
the UTC time represented by timestamp, converted to the
tzinfo timezone, one only ends up with a correct value
if tzinfo is a perfect match for whatever 'localtime'
is.  This seems useless as well as counterintuitive,
since one must therefore do this:

datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo)

to get what's desired.  Or, one can do:

datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo)

Both of these seem unreasonably complex ways of doing
something simple: render this UTC timestamp as a
datetime in a specified timezone.

Similarly, I would expect datetimetz.now(tzinfo) to
return the current time in the zone specified by
tzinfo, but again this is not what it does.  Similarly,
you must do:

datetimetz.now(localtime_tz).astimezone(tzinfo)

or:

datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo)

to get the current time in the zone specified by
tzinfo. Given that these constructors *know* what the
UTC time is, why don't they behave more meaningfully? 
It seems to me that finding the current time in a
timezone, or rendering a timestamp as it would be seen
in a timezone, are common enough use cases, but I
cannot think of any use cases for what the constructors
actually do instead.