[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)
Victor Stinner victor.stinner at gmail.com
Thu Feb 16 13:53:57 CET 2012
- Previous message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Next message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 accurate.
On Windows, QueryPerformanceCounter() is less accurate than GetSystemTimeAsFileTime() for example: http://msdn.microsoft.com/en-us/magazine/cc163996.aspx (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.
Victor
- Previous message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Next message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]