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

Victor Stinner victor.stinner at gmail.com
Mon Feb 13 19:33:41 CET 2012

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:

Oh, I forgot to mention my main concern about datetime: many functions returning timestamp have an undefined starting point (an no timezone information ), and so cannot be converted to datetime:

Allowing datetime.datetime type just for few functions (like datetime.datetime or time.time) but not the others (raise an exception) is not an acceptable solution.

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

return datetime.datetime.fromtimestamp( os.stat(self.lockfile).stmtime)

Keep your code but just add timestamp=decimal.Decimal argument to os.stat() to get high-resolution timestamps! (well, you would at least avoid loss of precision loss if datetime is not improved to support nanosecond.)

* 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 don't know enough this topic to answer. Martin von Loewis should answer to this question!

* 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?

Yes. decimal.Decimal is already supported by all functions accepting float (all functions expecting timestamps).

Will users ever have to explicitly convert Decimal types to use other APIs?

Sorry, I don't understand. What do you mean?

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.

Users only get decimal.Decimal if they ask explicitly for decimal.Decimal. By default, they will still get float. Most users don't care of nanoseconds :-) If a library choose to return Decimal instead of float, it's a change in the library API unrelated to the PEP.

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.

IMO supporting nanosecond in datetime and timedelta is an orthogonal issue.

And yes, the PEP should maybe give better arguments against datetime :-) I will update the PEP to mention the starting point issue.

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

You're welcome :)

More information about the Python-Dev mailing list