datetime.datetime.strptime throws out an error for me, to reproduce, use the following block:

```
>>> import datetime
>>> import pytz
>>> d2 = datetime.datetime(2019, 9, 11, 18, 35, 17, 334000, tzinfo=pytz.timezone('CET'))
>>> d2.strftime('%Y%m%d%H%M%S%f%Z')
'20190911183517334000CET'
>>> datetime.datetime.strptime('20190911183517334000CET', '%Y%m%d%H%M%S%f%Z')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/envs/lab42/lib/python3.6/_strptime.py", line 565, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/opt/conda/envs/lab42/lib/python3.6/_strptime.py", line 362, in _strptime
    (data_string, format))
ValueError: time data '20190911183517334000CET' does not match format '%Y%m%d%H%M%S%f%Z'
>>> datetime.datetime.strptime('20190911183517334000', '%Y%m%d%H%M%S%f')
datetime.datetime(2019, 9, 11, 18, 35, 17, 334000)
```

so strptime could only handle the format without %Z.

This seems to be same as issue22377 where UTC, GMT and value time.tzname in the machine are the supported values.

Hi Yixing, thank you for your bug report. This issue has already been reported, and the discussion is in issue #22377.

In the short term I believe the solution will be to document the current behavior. In the long term there are some solutions, though I imagine none of them will be amazingly satisfying, because the output of %Z is basically freeform and doesn't necessarily match to an unambiguous offset. The best you'd be able to do would be %Z%z or %z%Z, but there will be many implementation challenges there.

resolution: duplicate
stage: resolved