%z is listed as a supported directive in the python 3 documentation (https://docs.python.org/3.5/library/time.html#time.strftime), but it doesn't actually do anything:

>>> from time import strptime
>>> strptime('+0000', '%z') == strptime('+0200', '%z')
True

As far as I can tell, there aren't any footnotes saying that %z might not be supported on some platforms, like it was back in python 2.

In case it matters, I'm using python 3.5.3 on linux.

Are you sure? It works for me:

>>> strptime("+0200", "%z").tm_gmtoff
7200
>>> strptime("+0000", "%z").tm_gmtoff
0

The "struct_time" class is documented as a named tuple, but the time zone offset is not one of the tuple elements, so isn’t going to be checked for equality.

I see. You're right, it does make a difference.

However, this behaviour is quite unexpected. Perhaps I just didn't read the docs carefully enough, but it wasn't clear to me that the time module had such half-baked support for time zones.

An unsuspecting user, like me, reads the documentation on strptime, which directs you to strftime. There you read that %z is a supported directive. Along the way you've come across the conversion table, which tells you that mktime() can convert struct_time objects to timestamps. But then when you try to parse a time string, the information gets lost somewhere along the way:

>>> mktime(strptime("+0000", "%z")) == mktime(strptime("+0200", "%z"))
True

If you visit the section about struct_time objects, you find this footnote:
"Changed in version 3.3: tm_gmtoff and tm_zone attributes are available on platforms with C library supporting the corresponding fields in struct tm."

But even after reading that, I'd still expect the tm_gmtoff attribute to have some sort of effect and not get silently discarded.

As far as I can see, the documentation only claims that “mktime” converts local time. If you saw a suggestion that it supports arbitrary time zones, please point it out.

No no, the docs are correct. This was definitely my mistake. I'm just trying to say that it's rather confusing how there's only partial support for time zones. When I saw that there is support for parsing the time zone offset, I assumed that the functions provided in the time module would be enough to solve my problem - having to rely on the datetime module to have proper time zone support caught me by surprise. It's quite counterintuitive.

We could change this to a documentation issue if you have any suggestions to make the documentation clearer.

I understand the “time” module is mainly a wrapper or emulator of the OS’s own strptime, mktime, etc functions, which explains some of these quirks.

Yes, that's exactly right.  'time' is a low-level os-function wrapper, and inherits many of the deficiencies of the platform.  datetime attempts to be a more comprehensive, portable solution.  (But even it has its quirks...timezones are *hard*.)

There's actually a footnote pointing out that %z is not supported by all libc implementations: https://docs.python.org/3/library/time.html#id2. Probably adding a note for %z in the strftime() table would be good.

See also Issue20281.

New changeset 305588c67cdede4ef127ada90c1557bc1ef7c200 by Hugo van Kemenade in branch 'main':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing footnote (GH-30354)
https://github.com/python/cpython/commit/305588c67cdede4ef127ada90c1557bc1ef7c200

New changeset 93dc1654dc3c925c062e19f0ef8587aa8961ef8a by Miss Islington (bot) in branch '3.10':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing footnote (GH-30354)
https://github.com/python/cpython/commit/93dc1654dc3c925c062e19f0ef8587aa8961ef8a

New changeset f869b56fe4be416d356fffc94b8b18fe65039929 by Miss Islington (bot) in branch '3.9':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing footnote (GH-30354)
https://github.com/python/cpython/commit/f869b56fe4be416d356fffc94b8b18fe65039929