> 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 _______________________________________________ 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
