> I see that you participated in the original discussion (msg107608).
> We settled on str(timezone.utc) == 'UTC+00:00' and this was clearly a
> deliberate choice.  I don't think we can revisit this now, but we can
> probably make strptime smart enough to parse UTC±hh:mm with %Z format
> code.

I see it advocates either 'UTC' or '+00:00' ('-00:00' is semantically
different) i.e., mutually exclusive options: UTC is special enough
(it is a real timezone that is widely used) to warrant 'UTC' name. On
the other hand '+HH:MM' (%:z) (note: *without* 'UTC' prefix) is easily
extendable for a fixed-offset tzinfo family and it allows to use %Z to
generate/parse date/time strings with rfc3339-like utc offset and the
"numeric" tzname() would stress that a fixed-offset datetime.timezone
doesn't represent "real" zoneinfo timezone.

UTC+HH:MM is neither here nor there: it is easily confusable with
deprecated :GMT+H, Etc/GMT-H zoneinfo timezones (I'm not sure about
the signs) and it doesn't help generate/parse isoformat() strings
e.g., it confuses dateutil.parser therefore *strftime('... %Z') with
datetime.timezone should be avoided.*

pytz is *the* module that exposes zoneinfo (*the* timezone database)
to Python. Its tzname() methods (and therefore strftime('%Z')) produce
timezone abbreviations such as 'UTC', 'EST', 'CST' (all %Z examples in
datetime docs) that may be ambiguous (the same abbreviation can be
used by several timezones) and in reverse -- a single timezone can use
several abbreviations for the same purpose (non-DST related). I find
'%Z%z' to be easier to read at a glance compared to %z along (imagine
you look at dozens timestamps at once e.g., in a log collected from
several machines).