[issue7229] Manual entry for time.daylight can be misleading
Georg Brandl
Alexander Belopolsky
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
anatoly techtonik
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
participants (3)
-
Alexander Belopolsky -
anatoly techtonik
-
Georg Brandl