Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #96602 > unrolled thread
| Started by | Tim Peters <tim.peters@gmail.com> |
|---|---|
| First post | 2015-09-14 15:22 -0500 |
| Last post | 2015-09-14 15:22 -0500 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? Tim Peters <tim.peters@gmail.com> - 2015-09-14 15:22 -0500
| From | Tim Peters <tim.peters@gmail.com> |
|---|---|
| Date | 2015-09-14 15:22 -0500 |
| Subject | Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? |
| Message-ID | <mailman.565.1442262194.8327.python-list@python.org> |
[Tim] >> It depends on how expensive .utcoffset() >> is, which in turn depends on how the tzinfo author implements it. [Alex] > No, it does not. In most time zones, UTC offset in seconds can be computed > by C code as a 4-byte integer Which is a specific implementation of .utcoffset(). Which likely has nothing to do with how most tzinfo authors will implement _their_ .utcoffset(). For example, look at any tzinfo.utcoffset() implementation that currently exists ;-) > faster > than CPython can look up the .utcoffset method. (At least for times > within a few years around now.) A programmer who makes it slower should > be fired. So any programmer who implements .utcoffset() in Python should be fired? That's the only way I can read that. > Yet I agree, "'premature optimization' applies at this time." I'm more worried now about premature firing ;-)
Back to top | Article view | comp.lang.python
csiph-web