[Datetime-SIG] Are there any "correct" implementations of tzinfo?

Tim Peters tim.peters at gmail.com
Mon Sep 14 21:49:53 CEST 2015

>> It would be nice to have!  .utcoffset() is an expensive operation
>> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
>> instead.

> If it  is just a question of optimization,

Yes.  If it's more than just that, then 495 doesn't actually solve the
problem of getting the correct UTC offset in all cases.

> datetime objects can be extended to cache utcoffset.  Note that PyPy
> have recently added caching of the hash values in datetime objects.  I
> merged their changes in our datetime.py, but it did not look like C
> implementation would benefit from it as much as pure python did.  I
> expect something similar from caching utcoffset: a measurable
> improvement for tzinfos implemented in Python and a wash for those
> implemented in C.  (A more promising optimization approach is to define a C
> API for tzinfo interface.)

There's no answer to this.  It depends on how expensive .utcoffset()
is, which in turn depends on how the tzinfo author implements it.

I don't care now fast it is.  But, even if I did, "premature
optimization" applies at this time ;-)

More information about the Python-list mailing list