[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> PEP author Victor asked
> (in http://mail.python.org/pipermail/python-dev/2012-February/116499.html):
>> Maybe I missed the answer, but how do you handle timestamp with an
>> unspecified starting point like os.times() or time.clock()? Should we
>> leave these function unchanged?
> If *all* you know is that it is monotonic, then you can't -- but then
> you don't really have resolution either, as the clock may well speed up
> or slow down.
> If you do have resolution, and the only problem is that you don't know
> what the epoch was, then you can figure that out well enough by (once
> per type per process) comparing it to something that does have an epoch,
> like time.gmtime().

Hum, I suppose that you can expect that time.time() - time.monotonic()
is constant or evolve very slowly. time.monotonic() should return a
number of second. But you are right, usually monotonic clocks are less

On Windows, QueryPerformanceCounter() is less accurate than
GetSystemTimeAsFileTime() for example:
(read the "The Issue of Frequency" section)

time.monotonic() (function added to Python 3.3) documentation should
maybe mention the second unit and the accuracy issue.