Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

@akeeman I'll note that your example uses pytz.timezone, which will generally give the wrong answer when used (though this is entirely the fault of pytz for using a non-standard interface and very little can be done about it).

Tests go in Lib/test/datetimetester.py.

It seems that this pull request might be abandoned. @pganssle, is this change something you think should be pursued in light of the other time zone changes you have planned? Thanks!

@csabella The new time zone support doesn't really change things, because the stuff you would parse with %Z is not a unique representation of any sort of time zone anyway, so there's nothing automagical we could do that would just return a standard library time zone.

I went into considerably more detail on the bpo issue about the possible options for this interface. I don't particularly like the one that @akeeman has chosen, but it's close enough to one that I'd accept as a compromise 😉.

If this or any other PR were to succeed, though, it would need:

1. Tests (and probably pretty extensive ones, since parsing is tricky)
2. To drop the reference to pytz, which would do the wrong thing and be misleading anyway.
3. More extensive documentation in the datetime documentation about how to use this.

That said, regardless of any criticisms I have about the interface, I appreciate that @akeeman took the time to bring up this issue and to take an initial crack at the implementation, so thank you Arjan!

@pganssle, thank you for your response. @akeeman, please let us know if you are interested in pursuing this pull request by applying the changes that Paul requested and by rebasing to resolve the merge conflicts. If you are no longer interested in this, then I'll close the PR to allow someone else to attempt it. Thanks!

@pganssle Thanks for the comment. I hope that there are better ways to do it too, but mostly wanted to start a discussion and have some ideas going. I'll read your linked issue soon. I'd like the best implementation, and that doesn't necessarily have to be this one. (@csabella "[...] then I'll close the PR to allow someone else to attempt it." -> if someone has interest to do it, you can make an attempt right now if you ask me. Don't hesitate to move this pr aside if there's a better one.)

As for this pr; The given points are clearly valid, and should be implemented. I'll try to make some time soon.

After reading the bpo issue, can I say that you, @pganssle, would like to see the arg I've called tzname_to_tzinfo to accept both a mapping of tzstr -> tz and a callable like handle_tzinfo(dt, tzstr)? Of course we could rename tzname_to_tzinfo to the much shorter tzinfos too...

Changed things to

datetime.strptime("2019-05-01 00:00:00 UTC", "%Y-%m-%d %H:%M:%S %Z", infos)

where infos is either a mapping, or a callable

infos = {"UTC": datetime.timezone(datetime.timedelta(hours=0))}
# or
def infos(dt: datetime.datetime, tzname: str) -> datetime.timezone:
    # some spaghetti here

(I still have to add tests)