[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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
brought up).

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.