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

Victor Stinner victor.stinner at gmail.com
Thu Feb 16 10:51:05 CET 2012


2012/2/16 "Martin v. Löwis" <martin at v.loewis.de>:
>> Maybe an alternative PEP could be written that supports the filesystem
>> copying use case only, using some specialized ns APIs? I really think
>> that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
>
> I'm -1 on that, because it will make people write complicated code.

Python 3.3 *has already* APIs for nanosecond timestamps:
os.utimensat(), os.futimens(), signal.sigtimedwait(), etc. These
functions expect a (seconds: int, nanoseconds: int) tuple.

We have to decide before the Python 3.3 release if this API is just
fine, or if it should be changed. After the release, it will be more
difficult to change the API.

If os.utimensat() expects a tuple, it would be nice to have a function
getting time as a tuple, like the C language has the clock_gettime()
function to get a timestamp as a timespec structure.

During the discussion, many developers wanted a type allowing to do
arithmetic operations like t2-t1 to compute a delta, or t+delta to
"set" a timezone. It is possible to do arithmetic on a tuple, but it
is not practical and I don't like a type with a fixed resolution (in
some cases you need millisecond, microseconds or 100 ns resolution).

If you consider that the float loss of precision is not an issue for
nanoseconds, we should use float for os.utimensat(), os.futimens() and
signal.sigtimedwait(), just for consistency.

Victor


More information about the Python-Dev mailing list