os.clock() versus os.time() for measuring CPU-bound versus I/O-bound bottlenecks in Lua

When profiling a Lua routine to determine whether latency stems from CPU computation or external I/O, the standard library offers two timing primitives: os.clock() and os.time(). The objective is to select a timer that accurately reflects the observed delay without relying on non-portable extensions. os.clock() reports processor time consumed by the program, excluding time spent blocked on I/O, network, or system calls. os.time() returns wall-clock time but with one-second granularity, rendering it unsuitable for fine-grained profiling. Neither function is documented as monotonic, and the Lua standard does not guarantee sub-second wall-clock resolution. This creates a fundamental trade-off: using os.clock() may underrepresent I/O-bound latency, while os.time() lacks the resolution to capture short bottlenecks. Developers must therefore choose between CPU-time accuracy and wall-clock relevance within the constraints of standard Lua.

Which timer most accurately reflects true wait time for an I/O-bound section? Can os.clock() be interpreted to approximate wall-clock latency without OS-specific calls? What documented approach captures sub-second latency portably in standard Lua?