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

[Barry Warsaw]

On Feb 13, 2012, at 01:28 AM, Victor Stinner wrote:

>I'm still waiting for Nick Coghlan and Guido van Rossum for their
>decision on the PEP.

Thanks for continuing to work on this Victor.  I agree with the general
motivation behind the PEP, and appreciate your enthusiasm for improving Python
here.

However, I am still -1 on the solution proposed by the PEP.  I still think
that migrating to datetime use is a better way to go, rather than a
proliferation of the data types used to represent timestamps, along with an
API to specify the type of data returned.

Let's look at each item in the PEPs rationale for discarding the use of
datetimes:

 * datetime.datetime only supports microsecond resolution, but can be enhanced
   to support nanosecond.

Great!  JFDI!

 * datetime.datetime has issues with timezone. For example, a datetime object
   without timezone and a datetime with a timezone cannot be compared.

This may be so, but I don't think it causes fatal problems with this
approach.  The APIs returning high resolution datetimes should return naive
(i.e. timezone-less) datetimes.  If this is done consistently, then most math
on such datetimes (along with high resolution timedeltas) should Just Work.

I'm looking at a use case from my flufl.lock library:

            return datetime.datetime.fromtimestamp(
                os.stat(self._lockfile).st_mtime)

and later, this value is compared:

            datetime.datetime.now() > release_time

So with higher resolution naive datetimes, this would still work.  I think
it's fine if the user wants to mix naive and timezone-ful datetimes, they will
have to resolve the compatibility issues, but I think that will be the
minority of cases.

So this issue should not be a blocker for high resolution datetimes (and
timedeltas).

 * datetime.datetime has ordering issues with daylight saving time (DST) in
   the duplicate hour of switching from DST to normal time.

Sure, but only for timezone-ful datetimes, right?  I can live with that, since
I have to live with that for all non-naive datetimes anyway, and as I
mentioned, I don't think in general it will be a practical problem when using
high resolution datetime.s

 * datetime.datetime is not as well integrated than Epoch timestamps, some
   functions don't accept this type as input. For example, os.utime() expects
   a tuple of Epoch timestamps.

So, by implication, Decimal is better integrated by virtue of its ability to
be coerced to floats and other numeric stack types?  Will users ever have to
explicitly convert Decimal types to use other APIs?

I don't think this one is insurmountable either.  We could certainly improve
the compatibility of datetimes with other APIs, and in fact, I think we should
regardless of which direction this PEP takes.  You could even argue for EIBTI
in converting from datetimes to types acceptable to those other APIs, many of
which derive their argument types by virtue of the C APIs underneath.

It bothers me that the PEP is proposing that users will now have to be
prepared to handle yet another (and potentially *many* more) data types coming
from what are essentially datetime-like APIs.

If it really is impossible or suboptimal to build high resolution datetimes
and timedeltas, and to use them in these APIs, then at the very least, the PEP
needs a stronger rationale for why this is.  But I think ultimately, it would
be better for Python to improve the resolution, and API support for datetimes
and timestamps.

In any case, thanks for your work in this (and so many other!) areas.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120213/4a8482c4/attachment.pgp>