On Wed, Feb 15, 2012 at 10:11, "Martin v. Löwis" <[email protected]> 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 _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com