Why Does a Linux Program Care About Time?
Think about a simple food delivery app. It needs to know when an order was placed (calendar time), how long the delivery took (elapsed time), and how much CPU was used to process the payment (process time). Linux gives you system calls to measure all three. Before diving into those calls, you need to understand the two fundamental categories of time.
Keywords in This Post
Real time is time as humans understand it — the kind measured by a wall clock. Linux programs use real time in two ways:
| Sub-type | What it measures | Everyday example |
|---|---|---|
| Calendar Time | Absolute time from a fixed standard reference point | Timestamp on a bank transaction: 2025-05-15 10:30:00 |
| Elapsed (Wall Clock) Time | Time difference from when a process started | A stopwatch showing how long a compiler has been running |
Calendar time is used when you need to stamp data with the exact moment something happened — like logging when a user logged in, or when a file was modified.
Elapsed time is used when you care about duration — like measuring how long a video encoding job took.
Process time is not the time on your wall clock. It is the amount of CPU time that a process has actually consumed. Consider this analogy:
Analogy: You submit an essay to a teacher. You gave it to them at 9 AM and got it back at 5 PM — that’s 8 hours of elapsed time. But the teacher only spent 30 minutes actually reading it. Those 30 minutes are the process time. The rest of the time it was just sitting on the desk (waiting in the OS scheduler queue).
| Component | What it counts | Example |
|---|---|---|
| User CPU Time | CPU time spent running your code (user-space) | Sorting an array, computing a hash, parsing JSON |
| System CPU Time | CPU time spent by the kernel on behalf of your process | Reading a file, creating a socket, allocating memory with mmap() |
Here is a visual breakdown of the relationship between elapsed (wall clock) time and the two components of process time for a running program:
| PROCESS TIMELINE (example: compiling a C file) | |||||||
| Time → | t=0 | t=1s | t=2s | t=3s | t=4s | t=5s (end) | Total |
| Wall Clock | ▶ | ▶ | ▶ | ▶ | ▶ | ■ | 5.0 s |
| User CPU | ▶ | (sleep) | ▶ | (sleep) | ▶ | ■ | 1.2 s |
| Sys CPU | (i/o wait) | ▶ | (i/o wait) | ▶ | (sleep) | ■ | 0.8 s |
Notice: wall clock time was 5 seconds, but the process only used 2 seconds of actual CPU. The rest of the time the process was sleeping, waiting for disk I/O, or was paused by the scheduler.
Every computer has a built-in hardware clock (often called the RTC — Real Time Clock). This is a tiny chip that keeps ticking even when your computer is switched off (powered by a small battery on the motherboard). The Linux kernel reads this hardware clock at boot time to initialize its internal software clock.
| Clock Type | Where it lives | Used for |
|---|---|---|
| Hardware RTC | On the motherboard chip | Keeping time when powered off; initialising kernel at boot |
| Kernel Software Clock | In kernel memory (volatile) | All time-related system calls while system is running |
| Concept | One-line definition |
|---|---|
| Real Time | Time as the wall clock sees it |
| Calendar Time | Absolute time since a fixed reference (the Epoch) |
| Elapsed Time | Time since the process started |
| Process Time | Actual CPU time consumed by a process |
| User CPU Time | CPU used running your own code |
| System CPU Time | CPU used by the kernel on your behalf |
Up Next in This Series
Part 2 covers the Linux Epoch, the time_t data type, and the famous Year 2038 problem.