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

[Victor Stinner]

> 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:
 - time.clock(), time.wallclock(), time.monotonic(),
time.clock_gettime() (except for CLOCK_REALTIME)
 - time.clock_getres()
 - signal.get/setitimer()
 - os.wait3(), os.wait4(), resource.getrusage()
 - etc.

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

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