monotonic

Backport of time.monotonic() providing a clock that never goes backwards for Python 2 and pre-3.3 Python 3

Library
PyPI
v1.6
65stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
34/100Needs Attention
Development Activity0
Maintenance20
Community44
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
60/100Good
Architecture60
Code Quality55
Innovation35
Learning Curve90

monotonic is a small, single-module Python library that provides a monotonic() function returning a clock value that never goes backwards, even across system-clock adjustments, NTP updates, or daylight-saving changes. On Python 3.3 and newer it is simply an alias for the standard library’s time.monotonic(); on older interpreters it falls back to platform-specific implementations using clock_gettime on Linux/BSD/AIX, GetTickCount/GetTickCount64 on Windows, and mach_absolute_time on macOS.

The library’s own README states it is considered stable, complete, and will not receive further updates, since the functionality it backports has been part of the Python standard library since 3.3. It remains widely installed as a transitive dependency of older packages (such as early versions of requests and tqdm) that needed monotonic timing on Python 2 or early Python 3.

What You Get

  • A monotonic() function returning fractional seconds from a clock that never moves backwards, safe for measuring elapsed time across wall-clock adjustments
  • Automatic aliasing to the standard library’s time.monotonic() on Python 3.3+, so importing the package is a no-op wrapper on modern interpreters
  • Platform-specific C-level fallbacks (clock_gettime, GetTickCount/GetTickCount64, mach_absolute_time) for Linux, BSD, AIX, Windows, and OS X on older Python versions
  • A RuntimeError raised at import time if no suitable monotonic clock implementation exists for the current platform, rather than silently falling back to wall-clock time

Common Use Cases

  • Measuring elapsed time or implementing timeouts/retries in libraries that still needed to support Python 2 or early Python 3
  • Acting as a compatibility shim so a single codebase could call monotonic() uniformly regardless of Python version
  • Being pulled in transitively as a dependency of older HTTP or progress-bar libraries that required monotonic timing before it was standard

Under The Hood

Architecture - The entire library is one file, monotonic.py: on import, it first tries from time import monotonic (available on Python 3.3+) and simply re-exports it; if that import fails, it falls through a chain of ctypes-based platform detection blocks (Linux/BSD/AIX via clock_gettime against CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW, Windows via kernel32.GetTickCount64/GetTickCount, macOS via mach_absolute_time with timebase conversion) to construct an equivalent function; if none apply, module import itself raises RuntimeError. Tech Stack - Pure Python using only the standard library (ctypes, time, os, sys) with zero third-party dependencies, packaged via classic setuptools/setup.py with no build step. Code Quality - The module is small (170 lines) and has no dedicated test suite in the repository; correctness instead relies on delegating to the OS-level monotonic clock APIs and the CPython standard library alias path on modern Python, which is the actual code path exercised in virtually all current installs. API Design - The API is a single function with no configuration: from monotonic import monotonic; monotonic(), matching the standard library’s time.monotonic() signature exactly so it functions as a drop-in polyfill.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search