[issue7229] Manual entry for time.daylight can be misleading
Georg Brandl <georg@python.org> added the comment: It seems to me that the quoted function from bzr def local_time_offset(t=None): """Return offset of local zone from GMT, either at present or at time t.""" # python2.3 localtime() can't take None if t is None: t = time.time() if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone would be very helpful to add to the `time` module docs as an example. I have to agree with the OP that the current state of the docs is not as clear as it could be. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment: On Tue, Jan 11, 2011 at 1:56 PM, Georg Brandl <report@bugs.python.org> wrote: ..
It seems to me that the quoted function from bzr ... would be very helpful to add to the `time` module docs as an example.
The problem with this function is the same as with the doc patches that have been proposed so far. It is subtly wrong. See issue #1647654. Specifically, see the link to a bug in Hg mentioned in msg122166.
I have to agree with the OP that the current state of the docs is not as clear as it could be.
In some ways the state of the docs is reflective of the state of the code. C/POSIX API on which time module design is based is not very well suited to the age of smart phones and distributed VC systems. The whole idea that there is a static "system timezone" is absurd when a "system" is in your pocket or in the cloud. I agree that the docs can be improved, but I don't see patches that would constitute an improvement. I've explained what I would see as an improvement in my prior comments. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
anatoly techtonik <techtonik@gmail.com> added the comment: On Tue, Jan 11, 2011 at 9:42 PM, Alexander Belopolsky <report@bugs.python.org> wrote:
I have to agree with the OP that the current state of the docs is not as clear as it could be.
In some ways the state of the docs is reflective of the state of the code. C/POSIX API on which time module design is based is not very well suited to the age of smart phones and distributed VC systems. The whole idea that there is a static "system timezone" is absurd when a "system" is in your pocket or in the cloud.
I agree that the docs can be improved, but I don't see patches that would constitute an improvement. I've explained what I would see as an improvement in my prior comments.
Absurd need to be eliminated, but every time I touch datetime issues I am confused by the complexity of additional information and incompatibility of low-level C API with user needs. We need datetime FAQ for a reference and a collection of user stories to see what it possible (with examples/recipes) and what is impossible (with proposals/PEP) in current state. If I was in charge - I'd mark all datetime issues as release blockers for Py3k, so that all who wanted Py3k released ASAP dedicate their time to this problem. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________
participants (3)
-
Alexander Belopolsky -
anatoly techtonik
-
Georg Brandl