<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 4:22 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> faster<br>
> than CPython can look up the .utcoffset method. (At least for times<br>
> within a few years around now.) A programmer who makes it slower should<br>
> be fired.<br>
<br>
</span>So any programmer who implements .utcoffset() in Python should be<br>
fired?  That's the only way I can read that.</blockquote></div><br>No, no!  I've already conceded that caching UTC offset will probably help pure Python implementations.  PyPy folks have established this fact for hash and I am willing to extrapolate their results to UTC offset.  I am only trying to say that if we decide to bring a fast TZ database to CPython, pure python tzinfo interface will likely become our main bottleneck, not the speed with which C code can compute the offset value.</div></div>