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

[Tim Peters]

[Tim]
>> 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.

[Alex]
> 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 ;-)