[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Am 14.02.2012 23:29, schrieb Barry Warsaw:
> I think I will just state my reasoning one last time and then leave it to the
> BDFL or BDFOP to make the final decision.
I'd like to remind people what the original point of the PEP process
was: to avoid going in cycles in discussions. To achieve this, the PEP
author is supposed to record all objections in the PEP, even if he
disagrees (and may state rebuttals for each objection that people
So, Victor: please record all objections in a separate section of the
PEP, rather than just rebutting in them in the PEP (as is currently the
> My primary concern with the PEP is adding to users confusion when they have to
> handle (at least) 5 different types[*] that represent time in Python.
I agree with Barry here (despite having voiced support for using Decimal
before): datetime.datetime *is* the right data type to represent time
stamps. If it means that it needs to be improved before it can be used
in practice, then so be it - improve it.
I think improving datetime needs to go in two directions:
a) arbitrary-precision second fractions. My motivation for
proposing/supporting Decimal was that it can support arbitrary
precision, unlike any of the alternatives (except for using
numerator/denominator pairs). So just adding nanosecond resolution
to datetime is not enough: it needs to support arbitrary decimal
fractions (it doesn't need to support non-decimal fractions, IMO).
b) distinction between universal time and local time. This distinction
is currently blurred; there should be prominent API to determine
whether a point-in-time is meant as universal time or local time.
In terminology of the datetime documentation, there needs to be
builtin support for "aware" (rather than "naive") UTC time, even
if that's the only timezone that comes with Python.