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

Nick Coghlan ncoghlan at gmail.com
Wed Feb 15 12:43:17 CET 2012

On Wed, Feb 15, 2012 at 7:11 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

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.

By contrast, I think the only remotely viable choices for arbitrary precision low level timestamp APIs are decimal.Decimal and datetime.timedelta. The "unknown epoch" problem makes it impossible to consistently produce datetime.datetime objects, and an API that inconsistently returned either datetime.datetime or datetime.timedelta for operations that currently consistently return float objects would just be annoying.

However, I still think that decimal.Decimal is the right choice. There's nothing wrong with layering APIs, and the core concept of a timestamp is simply a number representing a certain number of seconds. We already have a data type that lets us represent a numeric value to arbitrary precision: decimal.Decimal.

Instead of trying to hoist all those APIs up to a higher semantic level, I'd prefer to just leave them as they are now: dealing with numbers (originally ints, then floats to support microseconds, now decimal.Decimal to support nanoseconds and any future increases in precision). If the higher level semantic API is incomplete, then we should complete it instead of trying to mash the two different layers together indiscriminately.

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

If our core timestamp representation is decimal.Decimal, this is trivial to implement for both datetime and timedelta - just store the seconds component as a decimal.Decimal instance.

If not, we'd have to come up with some other way of obtaining arbitrary precision numeric storage (which seems rather wasteful).

Even if we end up going down the datetime.timedelta path for the os module APIs, that's still the way I would want to go - arranging for timedelta.total_seconds() to return a Decimal value, rather than some other clumsy alternative like having a separate total_nanoseconds() function that returned a large integer.

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.

As of 3.2, the datetime module already has full support for arbitrary fixed offsets from UTC, including datetime.timezone.utc (i.e. UTC+0), which allows timezone aware UTC. For 3.2+, you should only need a third party library like pytz if you want to support named timezones (including daylight savings changes).

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list