Message126037
| 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. |
|