[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 ;-) -- https://mail.python.org/mailman/listinfo/python-list
