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

[Nick Coghlan]

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