Yes, this is because of the limitations of the underlying system call. The results you'll get really depend on your platform.
On Windows, the system call always returns a signed 64-bit integer (which is the divided by the counter frequency). So it should not wrap on any reasonable time scale.
On Linux the underlying integer is either signed 32-bit or signed 64-bit depending on whether your platform is 32-bit or 64-bit system. It is also further divided by the frequency of the counter so a 32-bit integer could definitely wrap after several hours.
On Linux you should really be using the newer clock_gettime() system call rather than clock(), which shouldn't have this wrap around problem. If you have Python 3.3 or newer it's as simple as:
time.clock_gettime(time.CLOCK_PROCESS_CPUTIME_ID)
If you have an older version of Python, you can either install a C API package like posix_timers
to give you clock_gettime(). Check out: https://pypi.python.org/pypi/posix_timers/
Alternatively, you can use ctypes to access it your self. There is a stack overflow question that shows how to do this with a monotonic clock here: How do I get monotonic time durations in python?
The only difference you would have to make is to define CLOCK_PROCESS_CPUTIME_ID = 2
and use that instead of CLOCK_MONOTONIC_RAW
.
However, the best answer is probably the one given by jonrsharpe, which is to use timeit or one of the other profiling tools that comes with Python.