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.

Author belopolsky
Recipients akira, belopolsky, berker.peksag, cool-RR, inglesp, p-ganssle, r.david.murray
Date 2018-10-29.17:13:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1540833189.81.0.788709270274.issue22377@psf.upfronthosting.co.za>
In-reply-to
Content
I think strptime should only accept %Z when it comes together with %z and not do any validation.

This is close to the current behavior.  %Z by itself is useless because even when it is accepted, the value is discarded:

>>> print(datetime.strptime('UTC', '%Z'))
1900-01-01 00:00:00

You have to use %z to get an aware datetime instance: 

>>> print(datetime.strptime('UTC+0000', '%Z%z'))
1900-01-01 00:00:00+00:00


The validation is already fairly lax:

>>> print(datetime.strptime('UTC+1234', '%Z%z'))
1900-01-01 00:00:00+12:34

I don't think this issue has anything to do with the availability of zoneinfo database.  Timezone abbreviations are often ambiguous and should only serve as a human-readable supplement to the UTC offset and cannot by itself be used as a TZ specification.
History
Date User Action Args
2018-10-29 17:13:09belopolskysetrecipients: + belopolsky, r.david.murray, cool-RR, akira, inglesp, berker.peksag, p-ganssle
2018-10-29 17:13:09belopolskysetmessageid: <1540833189.81.0.788709270274.issue22377@psf.upfronthosting.co.za>
2018-10-29 17:13:09belopolskylinkissue22377 messages
2018-10-29 17:13:09belopolskycreate