[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). _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
