This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author techtonik
Recipients belopolsky, docs@python, georg.brandl, napik, techtonik
Date 2011-01-11.21:22:22
SpamBayes Score 3.0516492e-07
Marked as misclassified No
Message-id <AANLkTi=g0pCiWqmeCuDOUFhf+pAg_0OMuKaQn+G82XOc@mail.gmail.com>
In-reply-to <AANLkTinFTkwCLOyn9f6rE2-wKr-iSJ-Pdk1Rd7yKTxmw@mail.gmail.com>
Content
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.
History
Date User Action Args
2011-01-11 21:22:24techtoniksetrecipients: + techtonik, georg.brandl, belopolsky, napik, docs@python
2011-01-11 21:22:22techtoniklinkissue7229 messages
2011-01-11 21:22:22techtonikcreate