[Datetime-SIG] PEP-431/495

[Tim Peters]

[Tim]
>> [...]
>> Stewart, I still don't grasp what your problem is.  The only concrete
>> example I've seen is dealing with this string:
>>
>>     2004-10-31 01:15 EST-05:00
>>
>> where you knew "EST" meant US/Eastern, but you haven't explained
>> exactly what you're trying to _do_ with it.  If you're trying to
>> create an aware datetime out of it in a post-PEP-495 pytz, then "the
>> obvious" way is:
>>
>> 1. Create a UTC datetime out of "2004-10-31 01:15" alone.
>> 2. Create timedelta(hours=-5) out of "-05:00" alone.
>> 3. Subtract the result of #2 from the result of #1, to convert to UTC for
>> real.
>> 4. Invoke .astimezone() on the result of #3, passing pytz's spelling
>> of "US/Eastern".

[Guido]
> Funny, I would have done it this way (but the outcome should be the same):
>
> 1. Create a naive datetime out of "2004-10-31 01:15" alone.
> 2. Create timedelta(hours=-5) out of "-05:00" alone.
> 3. Subtract the result of #2 from the result of #1 to get the UTC time as a
> naive datetime.
> 4. Use .replace(tzinfo=datetime.timezone.utc) to mark the result as UTC.
> 5. Invoke .astimezone() on the result of #3, passing pytz's spelling
> of "US/Eastern".
>
> Only #5 requires pytz (though you could use pytz.utc in #4 -- it doesn't
> matter).
>
> My reason for the extra step is philosophical: the datetime created in the
> first step is just a (date, time) combo that *doesn't know* its timezone
> yet. Only after step 3 do we have the designated point in time, so then we
> can mark it as UTC.
>
> Of course, since the result is the same, if Tim's version is faster that's a
> fine way to do it -- but IMO mine makes it clearer what's going on.

That's fine - I'm trying to get across the idea, not suggest a
specific implementation, and 4 steps are one less than 5 ;-)  An
actual speed-conscious implementation would create the datetime with
the US/Eastern timezone in my step #1 already.  Classic arithmetic
still gets the right result in #3 (timedelta subtraction ignores the
tzinfo, except just to copy it into the result).  The _point_ is that
then step #4 can call the cheaper .fromutc() instead (which requires
that the datetime invoking it already has the destination tzinfo).

You could do the same in yours by changing your #4 to attach
US/Eastern, and changing #5 to just invoke .fromutc().  It's a little
cheaper to attach the destination zone in #1, though (in all, requires
creating one fewer datetime object).