[Datetime-SIG] Are there any "correct" implementations of tzinfo?
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
> 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 Datetime-SIG