[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Wed Feb 15 10:11:57 CET 2012

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 case).

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.

Regards, Martin

More information about the Python-Dev mailing list