FWIW, I'm with Barry on this; doing more with the datetime types seems preferable to introducing yet more different stuff to date/time handling.
On Mon, Feb 13, 2012 at 19:33, Victor Stinner <victor.stin...@gmail.com> wrote: > 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. It seems fairly simple to suggest that the functions with an undefined starting point could return a timedelta instead of a datetime? >> * 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! Yes, this should only be an issue for dates with timezones. >> * 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). I suppose something like os.utime() could be changed to also accept datetimes. >> 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. Not if you use it to cast them aside for this issue. ;) Cheers, Dirkjan _______________________________________________ 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
