If a program uses the system time to schedule events or to implement
a timeout, it may fail to run events at the right moment or stop the
timeout too early or too late when the system time is changed manually or
adjusted automatically by NTP. A monotonic clock should be used
instead to not be affected by system time updates:
time.monotonic().

To measure the performance of a function, time.clock() can be used
but it is very different on Windows and on Unix. On Windows,
time.clock() includes time elapsed during sleep, whereas it does
not on Unix. time.clock() resolution is very good on Windows, but
very bad on Unix. The new time.perf_counter() function should be
used instead to always get the most precise performance counter with a
portable behaviour (ex: include time spend during sleep).

Until now, Python did not provide directly a portable
function to measure CPU time. time.clock() can be used on Unix,
but it has bad
resolution. resource.getrusage() or os.times() can also be
used on Unix, but they require to compute the sum of time
spent in kernel space and user space. The new time.process_time()
function acts as a portable counter that always measures CPU time
(excluding time elapsed during sleep) and has the best available
resolution.

Each operating system implements clocks and performance counters
differently, and it is useful to know exactly which function is used
and some properties of the clock like its resolution. The new
time.get_clock_info() function gives access to all available
information about each Python time function.

New functions:

time.monotonic(): timeout and scheduling, not affected by system
clock updates

time.perf_counter(): benchmarking, most precise clock for short
period

time.get_clock_info(): pybench program to display information about the
timer like the resolution

The time.clock() function is deprecated because it is not
portable: it behaves differently depending on the operating system.
time.perf_counter() or time.process_time() should be used
instead, depending on your requirements. time.clock() is marked as
deprecated but is not planned for removal.

Limitations:

The behaviour of clocks after a system suspend is not defined in the
documentation of new functions. The behaviour depends on the
operating system: see the Monotonic Clocks section below. Some
recent operating systems provide two clocks, one including time
elapsed during system suspsend, one not including this time. Most
operating systems only provide one kind of clock.

time.monotonic() and time.perf_counter() may or may not be adjusted.
For example, CLOCK_MONOTONIC is slewed on Linux, whereas
GetTickCount() is not adjusted on Windows.
time.get_clock_info('monotonic')['adjustable'] can be used to check
if the monotonic clock is adjustable or not.

No time.thread_time() function is proposed by this PEP because it is
not needed by Python standard library nor a common asked feature.
Such function would only be available on Windows and Linux. On
Linux, it is possible to use
time.clock_gettime(CLOCK_THREAD_CPUTIME_ID). On Windows, ctypes or
another module can be used to call the GetThreadTimes()
function.

Monotonic clock, i.e. cannot go backward. It is not affected by system
clock updates. The reference point of the returned value is
undefined, so that only the difference between the results of
consecutive calls is valid and is a number of seconds.

On Windows versions older than Vista, time.monotonic() detects
GetTickCount() integer overflow (32 bits, roll-over after 49.7
days). It increases an internal epoch (reference time by) 232 each time that an overflow is detected. The epoch is stored
in the process-local state and so
the value of time.monotonic() may be different in two Python
processes running for more than 49 days. On more recent versions of
Windows and on other operating systems, time.monotonic() is
system-wide.

Performance counter with the highest available resolution to measure a
short duration. It does include time elapsed during sleep and is
system-wide. The reference point of the returned value is undefined,
so that only the difference between the results of consecutive calls
is valid and is a number of seconds.

Sum of the system and user CPU time of the current process. It does
not include time elapsed during sleep. It is process-wide by
definition. The reference point of the returned value is undefined,
so that only the difference between the results of consecutive calls
is valid.

Suspend execution for the given number of seconds. The actual
suspension time may be less than that requested because any caught
signal will terminate the time.sleep() following execution of that
signal's catching routine. Also, the suspension time may be longer
than requested by an arbitrary amount because of the scheduling of
other activity in the system.

On Unix, return the current processor time as a floating point number
expressed in seconds. It is process-wide by definition. The resolution,
and in fact the very definition of the meaning of "processor time",
depends on that of the C function of the same name, but in any case,
this is the function to use for benchmarking Python or timing
algorithms.

On Windows, this function returns wall-clock seconds elapsed since the
first call to this function, as a floating point number, based on the
Win32 function QueryPerformanceCounter(). The resolution is
typically better than one microsecond. It is system-wide.

time.steady(): "steady" is ambiguous: it means different things to
different people. For example, on Linux, CLOCK_MONOTONIC is
adjusted. If we uses the real time as the reference clock, we may
say that CLOCK_MONOTONIC is steady. But CLOCK_MONOTONIC gets
suspended on system suspend, whereas real time includes any time
spent in suspend.

time.timeout_clock()

time.wallclock(): time.monotonic() is not the system time aka the
"wall clock", but a monotonic clock with an unspecified starting
point.

The name "time.try_monotonic()" was also proposed for an older
version of time.monotonic() which would fall back to the system
time when no monotonic clock was available.

To not have to define high-level clocks, which is a difficult task, a
simpler approach is to only expose operating system clocks.
time.clock_gettime() and related clock identifiers were already added
to Python 3.3 for example.

The PEP as proposed offers a few new clocks, but their guarantees
are deliberately loose in order to offer useful clocks on different
platforms. This inherently embeds policy in the calls, and the
caller must thus choose a policy.

The "choose a clock" approach suggests an additional API to let
callers implement their own policy if necessary
by making most platform clocks available and letting the caller pick amongst them.
The PEP's suggested clocks are still expected to be available for the common
simple use cases.

To do this two facilities are needed:
an enumeration of clocks, and metadata on the clocks to enable the user to
evaluate their suitability.

The primary interface is a function make simple choices easy:
the caller can use time.get_clock(*flags) with some combination of flags.
This includes at least:

time.MONOTONIC: clock cannot go backward

time.STEADY: clock rate is steady

time.ADJUSTED: clock may be adjusted, for example by NTP

time.HIGHRES: clock with the highest resolution

It returns a clock object with a .now() method returning the current time.
The clock object is annotated with metadata describing the clock feature set;
its .flags field will contain at least all the requested flags.

time.get_clock() returns None if no matching clock is found and so calls can
be chained using the or operator. Example of a simple policy decision:

The available clocks always at least include a wrapper for time.time(),
so a final call with no flags can always be used to obtain a working clock.

Examples of flags of system clocks:

QueryPerformanceCounter: MONOTONIC | HIGHRES

GetTickCount: MONOTONIC | STEADY

CLOCK_MONOTONIC: MONOTONIC | STEADY (or only MONOTONIC on Linux)

CLOCK_MONOTONIC_RAW: MONOTONIC | STEADY

gettimeofday(): (no flag)

The clock objects contain other metadata including the clock flags
with additional feature flags above those listed above, the name
of the underlying OS facility, and clock precisions.

time.get_clock() still chooses a single clock; an enumeration
facility is also required.
The most obvious method is to offer time.get_clocks() with the
same signature as time.get_clock(), but returning a sequence
of all clocks matching the requested flags.
Requesting no flags would thus enumerate all available clocks,
allowing the caller to make an arbitrary choice amongst them based
on their metadata.

The amount of deviation of measurements by a given instrument from
true values. See also Accuracy and precision.
Inaccuracy in clocks may be caused by lack of precision, drift, or an
incorrect initial setting of the clock (e.g., timing of threads is
inherently inaccurate because perfect synchronization in resetting
counters is quite difficult).

Adjusted:

Resetting a clock to the correct time. This may be done either
with a <Step> or by <Slewing>.

Civil Time:

Time of day; external to the system. 10:45:13am is a Civil time;
45 seconds is not. Provided by existing function
time.localtime() and time.gmtime(). Not changed by this
PEP.

Clock:

An instrument for measuring time. Different clocks have different
characteristics; for example, a clock with nanosecond
<precision> may start to <drift> after a few minutes, while a less
precise clock remained accurate for days. This PEP is primarily
concerned with clocks which use a unit of seconds.

Counter:

A clock which increments each time a certain event occurs. A
counter is strictly monotonic, but not a monotonic clock. It can
be used to generate a unique (and ordered) timestamp, but these
timestamps cannot be mapped to <civil time>; tick creation may well
be bursty, with several advances in the same millisecond followed
by several days without any advance.

CPU Time:

A measure of how much CPU effort has been spent on a certain task.
CPU seconds are often normalized (so that a variable number can
occur in the same actual second). CPU seconds can be important
when profiling, but they do not map directly to user response time,
nor are they directly comparable to (real time) seconds.

Drift:

The accumulated error against "true" time, as defined externally to
the system. Drift may be due to imprecision, or to a difference
between the average rate at which clock time advances and that of
real time.

Epoch:

The reference point of a clock. For clocks providing <civil time>,
this is often midnight as the day (and year) rolled over to January
1, 1970. For a <clock_monotonic> clock, the epoch may be undefined
(represented as None).

Latency:

Delay. By the time a clock call returns, the <real time> has
advanced, possibly by more than the precision of the clock.

Monotonic:

The characteristics expected of a monotonic clock in practice.
Moving in at most one direction; for clocks, that direction is
forward. The <clock> should also be <steady>, and should be
convertible to a unit of seconds. The tradeoffs often include lack
of a defined <epoch> or mapping to <Civil Time>.

Precision:

The amount of deviation among measurements of the same physical
value by a single instrument. Imprecision in clocks may be caused by
a fluctuation of the rate at which clock time advances relative to
real time, including clock adjustment by slewing.

Process Time:

Time elapsed since the process began. It is typically measured in
<CPU time> rather than <real time>, and typically does not advance
while the process is suspended.

Real Time:

Time in the real world. This differs from <Civil time> in that it
is not <adjusted>, but they should otherwise advance in lockstep.
It is not related to the "real time" of "Real Time [Operating]
Systems". It is sometimes called "wall clock time" to avoid that
ambiguity; unfortunately, that introduces different ambiguities.

Resolution:

The smallest difference between two physical values that results
in a different measurement by a given instrument.

Slew:

A slight change to a clock's speed, usually intended to correct
<drift> with respect to an external authority.

Stability:

Persistence of accuracy. A measure of expected <drift>.

Steady:

A clock with high <stability> and relatively high <accuracy> and
<precision>. In practice, it is often used to indicate a
<clock_monotonic> clock, but places greater emphasis on the
consistency of the duration between subsequent ticks.

Step:

An instantaneous change in the represented time. Instead of
speeding or slowing the clock (<slew>), a single offset is
permanently added.

System Time:

Time as represented by the Operating System.

Thread Time:

Time elapsed since the thread began. It is typically measured in
<CPU time> rather than <real time>, and typically does not advance
while the thread is idle.

Wallclock:

What the clock on the wall says. This is typically used as a
synonym for <real time>; unfortunately, wall time is itself
ambiguous.

HPET: A High Precision Event Timer (HPET) chip consists of a 64-bit
up-counter (main counter) counting at least at 10 MHz and a set of
up to 256 comparators (at least 3). Each HPET can have up to 32
timers. HPET can cause around 3 seconds of drift per day.

TSC (Time Stamp Counter): Historically, the TSC increased with every
internal processor clock cycle, but now the rate is usually constant
(even if the processor changes frequency) and usually equals the
maximum processor frequency. Multiple cores have different TSC
values. Hibernation of system will reset TSC value. The RDTSC
instruction can be used to read this counter. CPU frequency scaling
for power saving.

Cyclone: The Cyclone timer uses a 32-bit counter on IBM Extended
X-Architecture (EXA) chipsets which include computers that use the
IBM "Summit" series chipsets (ex: x440). This is available in IA32
and IA64 architectures.

There were 4 implementations of the time in the Linux kernel: UTIME
(1996), timer wheel (1997), HRT (2001) and hrtimers (2007). The
latter is the result of the "high-res-timers" project started by
George Anzinger in 2001, with contributions by Thomas Gleixner and
Douglas Niehaus. The hrtimers implementation was merged into Linux
2.6.21, released in 2007.

hrtimers supports various clock sources. It sets a priority to each
source to decide which one will be used. Linux supports the following
clock sources:

tsc

hpet

pit

pmtmr: ACPI Power Management Timer

cyclone

High-resolution timers are not supported on all hardware
architectures. They are at least provided on x86/x86_64, ARM and
PowerPC.

Reading a hardware clock has a cost. The following table compares
the performance of different hardware clocks on Linux 3.3 with Intel
Core i7-2600 at 3.40GHz (8 cores). The bench_time.c program
was used to fill these tables.

Function

TSC

ACPI PM

HPET

time()

2 ns

2 ns

2 ns

CLOCK_REALTIME_COARSE

10 ns

10 ns

10 ns

CLOCK_MONOTONIC_COARSE

12 ns

13 ns

12 ns

CLOCK_THREAD_CPUTIME_ID

134 ns

135 ns

135 ns

CLOCK_PROCESS_CPUTIME_ID

127 ns

129 ns

129 ns

clock()

146 ns

146 ns

143 ns

gettimeofday()

23 ns

726 ns

637 ns

CLOCK_MONOTONIC_RAW

31 ns

716 ns

607 ns

CLOCK_REALTIME

27 ns

707 ns

629 ns

CLOCK_MONOTONIC

27 ns

723 ns

635 ns

FreeBSD 8.0 in kvm with hardware virtualization:

Function

TSC

ACPI-Safe

HPET

i8254

time()

191 ns

188 ns

189 ns

188 ns

CLOCK_SECOND

187 ns

184 ns

187 ns

183 ns

CLOCK_REALTIME_FAST

189 ns

180 ns

187 ns

190 ns

CLOCK_UPTIME_FAST

191 ns

185 ns

186 ns

196 ns

CLOCK_MONOTONIC_FAST

188 ns

187 ns

188 ns

189 ns

CLOCK_THREAD_CPUTIME_ID

208 ns

206 ns

207 ns

220 ns

CLOCK_VIRTUAL

280 ns

279 ns

283 ns

296 ns

CLOCK_PROF

289 ns

280 ns

282 ns

286 ns

clock()

342 ns

340 ns

337 ns

344 ns

CLOCK_UPTIME_PRECISE

197 ns

10380 ns

4402 ns

4097 ns

CLOCK_REALTIME

196 ns

10376 ns

4337 ns

4054 ns

CLOCK_MONOTONIC_PRECISE

198 ns

10493 ns

4413 ns

3958 ns

CLOCK_UPTIME

197 ns

10523 ns

4458 ns

4058 ns

gettimeofday()

202 ns

10524 ns

4186 ns

3962 ns

CLOCK_REALTIME_PRECISE

197 ns

10599 ns

4394 ns

4060 ns

CLOCK_MONOTONIC

201 ns

10766 ns

4498 ns

3943 ns

Each function was called 100,000 times and CLOCK_MONOTONIC was used to
get the time before and after. The benchmark was run 5 times, keeping
the minimum time.

"slewing": change the clock frequency to be slightly faster or
slower (which is done with adjtime()). Since the slew rate is
limited to 0.5 millisecond per second, each second of adjustment requires an
amortization interval of 2000 seconds. Thus, an adjustment of many
seconds can take hours or days to amortize.

"stepping": jump by a large amount in a single discrete step (which
is done with settimeofday())

By default, the time is slewed if the offset is less than 128 ms, but
stepped otherwise.

Slewing is generally desirable (i.e. we should use CLOCK_MONOTONIC,
not CLOCK_MONOTONIC_RAW) if one wishes to measure "real" time (and not
a time-like object like CPU cycles). This is because the clock on the
other end of the NTP connection from you is probably better at keeping
time: hopefully that thirty-five thousand dollars of Cesium
timekeeping goodness is doing something better than your PC's $3
quartz crystal, after all.

The "C Resolution" column is the resolution of the underlying C
structure.

Examples of clock resolution on x86_64:

Name

Operating system

OS Resolution

Python Resolution

QueryPerformanceCounter

Windows Seven

10 ns

10 ns

CLOCK_HIGHRES

SunOS 5.11

2 ns

265 ns

CLOCK_MONOTONIC

Linux 3.0

1 ns

322 ns

CLOCK_MONOTONIC_RAW

Linux 3.3

1 ns

628 ns

CLOCK_BOOTTIME

Linux 3.3

1 ns

628 ns

mach_absolute_time()

Mac OS 10.6

1 ns

3 µs

CLOCK_MONOTONIC

FreeBSD 8.2

11 ns

5 µs

CLOCK_MONOTONIC

OpenBSD 5.0

10 ms

5 µs

CLOCK_UPTIME

FreeBSD 8.2

11 ns

6 µs

CLOCK_MONOTONIC_COARSE

Linux 3.3

1 ms

1 ms

CLOCK_MONOTONIC_COARSE

Linux 3.0

4 ms

4 ms

GetTickCount64()

Windows Seven

16 ms

15 ms

The "OS Resolution" is the resolution announced by the operating
system.
The "Python Resolution" is the smallest difference between two calls
to the time function computed in Python using the clock_resolution.py
program.

On Linux, NTP may adjust the CLOCK_MONOTONIC rate (slewed), but it cannot
jump backward.

CLOCK_MONOTONIC_RAW is specific to Linux. It is similar to
CLOCK_MONOTONIC, but provides access to a raw hardware-based time that
is not subject to NTP adjustments. CLOCK_MONOTONIC_RAW requires Linux
2.6.28 or later.

Linux 2.6.39 and glibc 2.14 introduces a new clock: CLOCK_BOOTTIME.
CLOCK_BOOTTIME is identical to CLOCK_MONOTONIC, except that it also
includes any time spent in suspend. Read also Waking systems from
suspend (March, 2011).

CLOCK_MONOTONIC stops while the machine is suspended.

Linux provides also CLOCK_MONOTONIC_COARSE since Linux 2.6.32. It is
similar to CLOCK_MONOTONIC, less precise but faster.

clock_gettime() fails if the system does not support the specified
clock, even if the standard C library supports it. For example,
CLOCK_MONOTONIC_RAW requires a kernel version 2.6.28 or later.

Windows XP: RDTSC instruction of Intel processors, the clock
frequency is the frequency of the processor (between 200 MHz and 3
GHz, usually greater than 1 GHz nowadays).

Windows 2000: ACPI power management timer, frequency = 3,549,545 Hz.
It can be forced through the "/usepmtimer" flag in boot.ini.

QueryPerformanceFrequency() should only be called once: the frequency
will not change while the system is running. It fails if the
installed hardware does not support a high-resolution performance
counter.

GetTickCount() and GetTickCount64() are monotonic, cannot fail and are
not adjusted by SetSystemTimeAdjustment(). MSDN documentation:
GetTickCount(),
GetTickCount64().
The resolution can be read using GetSystemTimeAdjustment().

The elapsed time retrieved by GetTickCount() or GetTickCount64()
includes time the system spends in sleep or hibernation.

The timeGetTime function retrieves the system time, in milliseconds.
The system time is the time elapsed since Windows was started. Read
the timeGetTime() documentation.

The return type of timeGetTime() is a 32-bit unsigned integer. As
GetTickCount(), timeGetTime() rolls over after 2^32 milliseconds (49.7
days).

The elapsed time retrieved by timeGetTime() includes time the system
spends in sleep.

The default precision of the timeGetTime function can be five
milliseconds or more, depending on the machine.

timeBeginPeriod() can be used to increase the precision of
timeGetTime() up to 1 millisecond, but it negatively affects power
consumption. Calling timeBeginPeriod() also affects the granularity
of some other timing calls, such as CreateWaitableTimer(),
WaitForSingleObject() and Sleep().

Note

timeGetTime() and timeBeginPeriod() are part the Windows multimedia
library and so require to link the program against winmm or to
dynamically load the library.

The Solaris OS has a CLOCK_HIGHRES timer that attempts to use an
optimal hardware source, and may give close to nanosecond resolution.
CLOCK_HIGHRES is the nonadjustable, high-resolution clock. For timers
created with a clockid_t value of CLOCK_HIGHRES, the system will
attempt to use an optimal hardware source.

The gethrtime() function returns the current high-resolution real
time. Time is expressed as nanoseconds since some arbitrary time in
the past; it is not correlated in any way to the time of day, and thus
is not subject to resetting or drifting by way of adjtime() or
settimeofday(). The hires timer is ideally suited to performance
measurement tasks, where cheap, accurate interval timing is required.

The linearity of gethrtime() is not preserved across a suspend-resume
cycle (Bug 4272663).

The "C Resolution" column is the resolution of the underlying C
structure.

Examples of clock resolution on x86_64:

Name

Operating system

OS Resolution

Python Resolution

CLOCK_REALTIME

SunOS 5.11

10 ms

238 ns

CLOCK_REALTIME

Linux 3.0

1 ns

238 ns

gettimeofday()

Mac OS 10.6

1 µs

4 µs

CLOCK_REALTIME

FreeBSD 8.2

11 ns

6 µs

CLOCK_REALTIME

OpenBSD 5.0

10 ms

5 µs

CLOCK_REALTIME_COARSE

Linux 3.3

1 ms

1 ms

CLOCK_REALTIME_COARSE

Linux 3.0

4 ms

4 ms

GetSystemTimeAsFileTime()

Windows Seven

16 ms

1 ms

ftime()

Windows Seven

-

1 ms

The "OS Resolution" is the resolution announced by the operating
system.
The "Python Resolution" is the smallest difference between two calls
to the time function computed in Python using the clock_resolution.py
program.

The process time cannot be set. It is not monotonic: the clocks stop
while the process is idle.

Name

C Resolution

Include Sleep

Include Suspend

GetProcessTimes()

100 ns

No

No

CLOCK_PROCESS_CPUTIME_ID

1 ns

No

No

getrusage(RUSAGE_SELF)

1 µs

No

No

times()

-

No

No

clock()

-

Yes on Windows, No otherwise

No

The "C Resolution" column is the resolution of the underlying C
structure.

Examples of clock resolution on x86_64:

Name

Operating system

OS Resolution

Python Resolution

CLOCK_PROCESS_CPUTIME_ID

Linux 3.3

1 ns

1 ns

CLOCK_PROF

FreeBSD 8.2

10 ms

1 µs

getrusage(RUSAGE_SELF)

FreeBSD 8.2

-

1 µs

getrusage(RUSAGE_SELF)

SunOS 5.11

-

1 µs

CLOCK_PROCESS_CPUTIME_ID

Linux 3.0

1 ns

1 µs

getrusage(RUSAGE_SELF)

Mac OS 10.6

-

5 µs

clock()

Mac OS 10.6

1 µs

5 µs

CLOCK_PROF

OpenBSD 5.0

-

5 µs

getrusage(RUSAGE_SELF)

Linux 3.0

-

4 ms

getrusage(RUSAGE_SELF)

OpenBSD 5.0

-

8 ms

clock()

FreeBSD 8.2

8 ms

8 ms

clock()

Linux 3.0

1 µs

10 ms

times()

Linux 3.0

10 ms

10 ms

clock()

OpenBSD 5.0

10 ms

10 ms

times()

OpenBSD 5.0

10 ms

10 ms

times()

Mac OS 10.6

10 ms

10 ms

clock()

SunOS 5.11

1 µs

10 ms

times()

SunOS 5.11

1 µs

10 ms

GetProcessTimes()

Windows Seven

16 ms

16 ms

clock()

Windows Seven

1 ms

1 ms

The "OS Resolution" is the resolution announced by the operating
system.
The "Python Resolution" is the smallest difference between two calls
to the time function computed in Python using the clock_resolution.py
program.

The thread time cannot be set. It is not monotonic: the clocks stop
while the thread is idle.

Name

C Resolution

Include Sleep

Include Suspend

CLOCK_THREAD_CPUTIME_ID

1 ns

Yes

Epoch changes

GetThreadTimes()

100 ns

No

?

The "C Resolution" column is the resolution of the underlying C
structure.

Examples of clock resolution on x86_64:

Name

Operating system

OS Resolution

Python Resolution

CLOCK_THREAD_CPUTIME_ID

FreeBSD 8.2

1 µs

1 µs

CLOCK_THREAD_CPUTIME_ID

Linux 3.3

1 ns

649 ns

GetThreadTimes()

Windows Seven

16 ms

16 ms

The "OS Resolution" is the resolution announced by the operating
system.
The "Python Resolution" is the smallest difference between two calls
to the time function computed in Python using the clock_resolution.py
program.

Suspend execution of the process for the given number of seconds.
Sleep is not affected by system time updates. Sleep is paused during
system suspend. For example, if a process sleeps for 60 seconds and
the system is suspended for 30 seconds in the middle of the sleep, the
sleep duration is 90 seconds in the real time.

Sleep can be interrupted by a signal: the function fails with EINTR.

Name

C Resolution

nanosleep()

1 ns

clock_nanosleep()

1 ns

usleep()

1 µs

delay()

1 µs

sleep()

1 sec

Other functions:

Name

C Resolution

sigtimedwait()

1 ns

pthread_cond_timedwait()

1 ns

sem_timedwait()

1 ns

select()

1 µs

epoll()

1 ms

poll()

1 ms

WaitForSingleObject()

1 ms

The "C Resolution" column is the resolution of the underlying C
structure.

If flags is TIMER_ABSTIME, then request is interpreted as an absolute
time as measured by the clock, clock_id. If request is less than or
equal to the current value of the clock, then clock_nanosleep()
returns immediately without suspending the calling thread.

POSIX.1 specifies that changing the value of the CLOCK_REALTIME clock
via clock_settime(2) shall have no effect on a thread that is blocked
on a relative clock_nanosleep().

Since Linux 2.6.28, select() uses high-resolution timers to handle the
timeout. A process has a "slack" attribute to configure the precision
of the timeout, the default slack is 50 microseconds. Before Linux
2.6.28, timeouts for select() were handled by the main timing
subsystem at a jiffy-level resolution. Read also High- (but not too
high-) resolution timeouts and
Timer slack.

sigtimedwait(). POSIX: "If the Monotonic Clock option is supported,
the CLOCK_MONOTONIC clock shall be used to measure the time
interval specified by the timeout argument."

pthread_cond_timedwait(), pthread_condattr_setclock(). "The default
value of the clock attribute shall refer to the system time."

sem_timedwait(): "If the Timers option is supported, the timeout
shall be based on the CLOCK_REALTIME clock. If the Timers option is
not supported, the timeout shall be based on the system time as
returned by the time() function. The precision of the timeout
shall be the precision of the clock on which it is based."

WaitForSingleObject(): use the same timer than GetTickCount() with
the same precision.