[Datetime-SIG] PEP-431/495

Tim Peters tim.peters at gmail.com
Thu Aug 27 21:21:39 CEST 2015

[Alexander Belopolsky <alexander.belopolsky at 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 ;-)

More information about the Datetime-SIG mailing list