[Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement (original) (raw)

Tim Peters tim.peters at gmail.com
Sat Sep 12 05:03:14 CEST 2015

[Random832 <random832 at fastmail.com>]

...

Also, can someone explain why this: >>> ET = pytz.timezone("America/NewYork") >>> datetime.strftime(datetime.now(ET) + timedelta(days=90), ... "%Y%m%d %H%M%S %Z %z") returns '20151210 214526 EDT -0400'

pytz lives in its own world here, and only uses eternally-fixed-offset zones. It's a magnificent hack to get around the lack of an "is_dst bit" in datetime's design, and effectively records that bit via which fixed-offset zone it attaches to the datetime.

The tradeoff is that, to get results you expect, you need to invoke pytz's .normalize() after doing any arithmetic (and pytz's doc are very clear about this - do read them). That's required for pytz to realize the tzinfo in the result is no longer appropriate for the result's date and time, so it can (if needed) replace it with a different fixed-offset tzinfo.

I don't know if I expected 214526 or 204526, but I certainly expected the timezone info to say EST -0500. If EST and EDT are apparently two distinct tzinfo values,

In pytz, they are. This isn't how tzinfos were intended to work in Python, but pytz does create an interesting set of tradeoffs.

then what exactly would a value landing near the "fall back" transition have given for fold? fold=1 but EDT?

As above, pytz is in its own world here. It doesn't need fold because it has its own hack for disambiguating local times in a fold.

And if EST and EDT are, against all rationality, distinct tzinfo values, then when exactly can fold ever actually be 1, and why is it needed?

pytz doesn't need it. "Hybrid" tzinfos do, because there is currently no way outside of pytz to disambiguate local times in a fold.

So, short course: if you ask questions about pytz's behavior, you're asking question about pytz, not really about Python's datetime.

More information about the Python-Dev mailing list