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