[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