This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: [BUG] datetime.strptime could not handle timezone
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: %Z in strptime doesn't match EST and others
View: 22377
Assigned To: Nosy List: Yixing Jiang, belopolsky, p-ganssle, xtreak
Priority: normal Keywords:

Created on 2019-09-12 13:48 by Yixing Jiang, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg352163 - (view) Author: Yixing Jiang (Yixing Jiang) Date: 2019-09-12 13:48
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.
msg352173 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-09-12 14:16
This seems to be same as issue22377 where UTC, GMT and value time.tzname in the machine are the supported values.
msg352174 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-09-12 14:18
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.
History
Date User Action Args
2022-04-11 14:59:20adminsetgithub: 82320
2019-09-12 14:18:36p-gansslesetstatus: open -> closed
superseder: %Z in strptime doesn't match EST and others
messages: + msg352174

resolution: duplicate
stage: resolved
2019-09-12 14:16:22xtreaksetnosy: + xtreak
messages: + msg352173
2019-09-12 14:05:29xtreaksettype: crash -> behavior
2019-09-12 14:04:31xtreaksetnosy: + belopolsky, p-ganssle
2019-09-12 13:48:05Yixing Jiangcreate