> 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 :) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
