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

Dirkjan Ochtman dirkjan at ochtman.nl
Wed Feb 15 10:38:47 CET 2012


On Wed, Feb 15, 2012 at 10:11, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> 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.

+1. And adding stuff to datetime to make it easier to get a unix
timestamp out (as proposed by Victor before, IIRC) would also be a
good thing in my book. I really want to be able to handle all my
date+time needs without ever importing time or calendar.

Cheers,

Dirkjan


More information about the Python-Dev mailing list