[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Dirkjan Ochtman
dirkjan at ochtman.nl
Tue Feb 14 14:11:01 CET 2012
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.stinner at 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
More information about the Python-Dev
mailing list