[Alexander Belopolsky alexander.belopolsky@gmail.com]

Dealing with simple time strings like this should really be one step:

...

...

...

ts = '2004-10-31 01:15 EST-05:00' dt = datetime.strptime(ts.replace('EST', '').replace(':', ''), '%Y-%m-%d %H%M %z') print(dt)

2004-10-31 01:15:00-05:00

It is unfortunate that we need to massage the input like this before passing it to datetime.strptime(). Ideally, datetime.strptime() should have a way to at least parse -05:00 as a fixed offset timezone.

However, this problem has nothing to do with PEP 495. Once you have the UTC offset - there is no ambiguity. The other 01:15 would be "2004-10-31 01:15 -04:00." The EST part is redundant and is dropped explicitly in my solution and not used in the solutions by Tim and Guido.

You're solving a different problem, though. I keep guessing at what Stuart really wants in the end, but my _best_ guess is that he wants an aware datetime in US/Eastern, not an aware datetime in some anonymous eternally-fixed-offset-of-minus-5-hours timezone. If he really wanted a fixed-offset zone, then I can't imagine why he would pick a string so unlikely as to just happen to show an ambiguous time in US/Eastern.

The relation to PEP 495 is the repeated claims that somehow or other it's easy to compute is_dst from the original string but very difficult (or something) to compute "fold". The points of the last few messages were: (1) mktime is a neither cheap nor reliable (in all cases) way to compute is_dst; and, (2) a user doesn't even have to know about "fold" to get a US/Eastern datetime in pytz from that string; and, (3) it's not expensive and is wholly reliable (in all cases) to compute "fold" in a post-PEP-495 pytz if for some unfathomable (to me ;-) ) reason Stewart really _does_ want to compute fold for its own sake from that string (do the dance I gave, then throw away everything except the fold bit).

And I agree that extending .strptime() is irrelevant to the PEP ;-)