Learn › Linux Foundations › Time
Final test: Chapter 16, Time. Twenty-five objectives on a real Debian 12 server: date formats beyond Chapter 1 including epoch seconds, a moment named with date -d, the time on a file with date -r, sleep in three forms, time and its real, user and sys lines on a program that waits and a program that computes, watch at two tempos, yes stopped by head, and seq in five forms. Fifty minutes, graded from the commands you run.
This chapter covers the following topics:
What you already know: Section 1.8 taught date, date -u, date +%F, date +%H:%M and date +%A. You can already ask the machine what the time is, and choose a simple format for the answer. Chapters 9 and 10 used sleep as a stand-in for a long job. This chapter teaches both properly and adds the four tools that measure, repeat, produce and count.
Objectives
After this chapter you can:
Use Start machine to open the real shared practice server. The output beside each command is a recorded example from the prepared files. Run the command in Terminal and inspect your own result. The shell keeps its working directory while its connection stays open; a reconnect or lesson change may start a new shell, so run pwd and return with cd ~ when a shorter timing/ path needs /home/admin. Paths beginning ~/timing/ work from any directory. The chapter assessment starts on a separate fresh machine. Its checks measure specific commands and results, not independent mastery.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> It counts whole seconds since 1 January 1970 at 00:00 UTC, a moment called the epoch. A program combines the moment with a time zone to show a weekday and local hour. Section 16.2 covers it.
>>> sleep asks the system to set the program aside and wake it later. It uses almost no processor time during the wait, although starting and waking it take a little work. That is why waiting and working look different when measured. Section 16.6 covers it.
>>> real is wall-clock time from start to finish, whatever the command was doing. The other two, user and sys, count processor time only, so a command that waits shows a large real and two small numbers beside it. Section 16.7 covers it.
>>> watch repeats until it is interrupted. Ctrl-C sends the interrupt, watch restores the screen and the prompt comes back. Nothing you typed is lost. Section 16.8 covers it.
>>> A pipe has two ends. When head has what it asked for it closes its end, and the next thing yes writes has nowhere to go, so the system ends it. yes never counts anything. Section 16.9 covers it.
This chapter measures, waits and repeats, so it needs commands that behave in a known way. The directory ~/timing holds three small programs written for that purpose, and a description of them.
Two of the three take about the same amount of time to finish, and spend it in opposite ways. That difference is the whole of Section 16.7.
Read the description of the directory first. It is the file ~/timing/README.txt, and a path written from the tilde reaches it from wherever you are standing.
prompt: admin@server1:~$ answer: cat timing/README.txt ||| cat ~/timing/README.txt ||| cat /home/admin/timing/README.txt output: server1: the timing directory ============================= Three small programs live here. They exist so that the tools in this chapter have something real to point at, and each one is deliberately lopsided so the difference between them is visible.
index-rebuild takes about two seconds, and spends almost all of it waiting. It prints a line, waits a second, prints a line, waits a second, and files a record in last-run.txt. checksum-pass takes about two seconds, and spends all of it working. It adds 320000 numbers together and prints the total, which is always 51199840000. queue-depth prints a two line report and stops. Its bytes never change, which makes it short enough to repeat on the screen.
Nothing here reads the clock, so what these programs print is the same on every machine. What the clock and the stopwatch report is not: those numbers belong to the moment you run them. hint: Section 16.1. The reading command from Chapter 5, then the path timing/README.txt, or ~/timing/README.txt from anywhere.
Three programs. index-rebuild waits, checksum-pass computes, and queue-depth prints two lines and stops. The last line of the description is the rule that governs this chapter: what the programs print never changes, and what the clock reports always does.
A Linux clock does not store a sentence such as "Thursday morning." date can express a moment as a count of seconds since 1 January 1970 at 00:00 UTC. That starting moment is called the epoch, and the count is called epoch seconds or a Unix timestamp. The system also tracks finer fractions of a second; %s prints whole seconds.
The weekday, month name and local hour are calculated from the moment and the chosen time zone when a program asks for them.
The format code %s asks date for the counter itself. Section 1.8 introduced the plus sign: it tells date that what follows is a format rather than an option.
prompt: admin@server1:~$ answer: date +%s output: 1788725177 hint: Section 16.2. The clock command from Section 1.8, a plus sign, then the code %s.
Your number is larger than the one above, because time passed between the machine writing this lesson's answer key and you running the command. Ten digits is the normal length today and stays that way until the year 2286.
This is the form to reach for when a number has to be compared or subtracted. Two timestamps subtract cleanly into a number of seconds; two sentences do not.
Section 1.8 used a few format codes. There are many more, and they can be mixed with ordinary characters. Slashes and colons are printed where you put them; a code such as %d is replaced by one field of the time.
These are the codes this chapter uses:
| Code | What it prints |
|---|---|
| %d | the day of the month, two digits |
| %m | the month, two digits |
| %Y | the year, four digits |
| %H | the hour, two digits, 00 to 23 |
| %M | the minute, two digits |
| %S | the second, two digits |
| %A | the weekday name in full |
| %s | seconds since the epoch |
Put slashes between three of them and you get the form used on paper in most of the world. Ask for the day, then the month, then the four digit year, all in one format.
prompt: admin@server1:~$ answer: date +%d/%m/%Y output: 06/09/2026 hint: Section 16.3. A plus sign, then the codes %d, %m and %Y from the table with a slash between them, all in one argument.
The line above is the day the answer key was captured, so your line shows a different date. The slashes are not codes, so date printed them where you put them. Swap the first two codes and you get the form used in the United States. Neither is more correct than the other, which is exactly why the year first order, %Y-%m-%d, is the one to use in file names: it cannot be misread. %F in Section 1.8 is a short name for that same order.
A format that contains a space needs quotes around it. Without them the shell splits the line at the space and hands date two separate arguments, and date does not understand the second one.
Chapter 8 taught quoting for exactly this reason. Either kind of quote works here. Ask for the year, month and day joined by hyphens, then a space, then the hour, minute and second joined by colons.
prompt: admin@server1:~$ answer: date '+%Y-%m-%d %H:%M:%S' ||| date "+%Y-%m-%d %H:%M:%S" output: 2026-09-06 20:06:17 hint: Section 16.3. The date codes joined by hyphens, then the time codes joined by colons, in one format after the plus sign, with quotes around the whole of it because it holds a space.
One argument, one line of output, and the moment in it is the moment you ran the command, not the one above. The colons between the hour, the minute and the second are ordinary characters, printed where you put them, the same way the slashes were.
This is the stamp to write into a log line or a report: it sorts correctly as text, because the largest unit comes first.
Everything so far asked for now. The -d option asks about a moment you name instead. date reads the moment out of the text you give it and prints it in the usual form.
The text can be a date, a date and a time, or a date and a time with a time zone. This chapter uses the plain form: four digit year, month, day, then the hour and minute. Ask about 2026-01-15 at 09:00.
prompt: admin@server1:~$ answer: date -d "2026-01-15 09:00" ||| date -d '2026-01-15 09:00' ||| date --date="2026-01-15 09:00" output: Thu Jan 15 09:00:00 UTC 2026 hint: Section 16.4. The clock command, the option -d, then "2026-01-15 09:00" in quotes because it holds a space.
The moment came back written out in full, with the weekday worked out for you and the time zone the machine is set to. This server is set to UTC, so the hour you typed is the hour that came back.
The quotes are needed for the same reason as in Exercise 16-4: the text holds a space. A date on its own needs no quotes.
The two halves combine. Name a moment with -d, then ask for one field of it with a format. This is how a script turns a date into the one piece it needs. Ask which weekday 2026-01-15 was.
prompt: admin@server1:~$ answer: date -d 2026-01-15 +%A ||| date -d "2026-01-15" +%A ||| date -d 2026-01-15 '+%A' output: Thursday hint: Section 16.4. The option -d with the date 2026-01-15, then the weekday code %A from Section 1.8 after it.
One word. No calendar was consulted and nothing was looked up: date turned the text into epoch seconds and then worked the weekday out of that number.
A number on its own is not a moment to -d: it would be read as a date. An at sign in front of the number says the number is epoch seconds.
That makes -d @ the other half of +%s. One turns a moment into a number, the other turns a number back into a moment. Ask what moment epoch second 0 names.
prompt: admin@server1:~$ answer: date -d @0 ||| date -d "@0" ||| date --date=@0 output: Thu Jan 1 00:00:00 UTC 1970 hint: Section 16.4. The option -d, then the number 0 with an at sign in front of it.
This is the epoch itself, the moment the counter starts from. Every timestamp on this machine is a count of seconds from this line.
This is the form to reach for when a log file holds bare timestamps and you need to know what they mean.
The conversion runs the other way with the two halves you already have: name the moment with -d, then ask for %s. Use the same moment as Exercise 16-5, 2026-01-15 at 09:00.
prompt: admin@server1:~$ answer: date -d "2026-01-15 09:00" +%s ||| date -d '2026-01-15 09:00' +%s output: 1768467600 hint: Section 16.4. The option -d with "2026-01-15 09:00" in quotes, then the format +%s from Exercise 16-2 after it.
The same moment as Exercise 16-5, counted instead of written. Two moments converted this way subtract into a number of seconds, which is how a script works out how old something is.
Every file carries its modification time, the moment its contents were last changed. The -r option (reference) tells date to read that time off a file instead of taking a moment from you.
Chapter 5 printed that same time on the Modify line of stat. date -r prints it on its own, in the full form, which is easier to read and easier to hand to another command. Read the time off ~/timing/README.txt, the file Exercise 16-1 printed.
prompt: admin@server1:~$ answer: date -r timing/README.txt ||| date -r ~/timing/README.txt ||| date -r /home/admin/timing/README.txt ||| date --reference=timing/README.txt output: Thu Jan 15 09:00:00 UTC 2026 hint: Section 16.5. The option -r, then the path timing/README.txt, or ~/timing/README.txt from anywhere.
That is the same moment Exercise 16-5 named. The prepared README.txt was given that modification time when the machine was built. Files you create later, including last-run.txt, have their own newer modification times.
sleep does one thing: it waits for the number of seconds you give it, then finishes. It prints nothing.
Waiting is not the same as being busy. sleep asks the system to set the program aside and wake it later. While it waits, the processor is available for other work; starting and waking the process still take a little processor time.
Run it and watch the prompt: it does not come back until the three seconds are up.
prompt: admin@server1:~$ answer: sleep 3 output: hint: Section 16.6. The waiting command and the number 3, nothing else. It takes no path, so it runs from any directory.
No output, and about three seconds before the prompt returned. The wait is the whole command.
Chapter 9 sent a wait to the background with a trailing ampersand, which is the way to keep working while something waits.
The number does not have to be whole. The sleep on this machine comes from GNU coreutils, the collection that supplies most of the standard Linux commands, and it accepts a decimal.
prompt: admin@server1:~$ answer: sleep 0.5 ||| sleep .5 output: hint: Section 16.6. The same waiting command with the number 0.5 instead of a whole number.
Short waits like this are what a script uses when it has to give something a moment to settle without holding everything up for a whole second.
This is an addition GNU made. POSIX, the standard that says what a Unix command must accept, requires only a whole number of seconds, so a script that has to run on other kinds of Unix sticks to whole seconds.
A letter after the number says which unit it is: s seconds, m minutes, h hours, d days. With no letter the number is seconds, which is why every command so far worked without one.
prompt: admin@server1:~$ answer: sleep 2s output: hint: Section 16.6. The number 2, then the letter s for seconds, with no space between them.
sleep 2s and sleep 2 are the same instruction. The letter is worth writing when the number is large: sleep 300 and sleep 5m are the same wait, and only one of them can be read at a glance.
A script may wait when the next step cannot start yet: a service has to release a file, a machine has to finish booting, or another program has to write something first. A fixed sleep is simple but does not prove the condition has become true. Inspect the condition after the wait rather than assuming it did.
~/timing/index-rebuild is written that way. It prints a line, waits a second, prints a line, waits a second, and then files a record.
prompt: admin@server1:~$ answer: timing/index-rebuild ||| ~/timing/index-rebuild ||| ./timing/index-rebuild ||| /home/admin/timing/index-rebuild output: index: reading the page list index: writing the term table index: rebuild complete index: record filed at timing/last-run.txt hint: Section 16.6. The path timing/index-rebuild, or ~/timing/index-rebuild from anywhere, and nothing else.
Four lines, with a pause you could see between the first three. The program spent about two seconds in total and almost none of it working.
The last line names a file. That file did not exist before you ran this, and Section 16.7 measures the same program, so it is worth reading now.
The record is an ordinary text file, ~/timing/last-run.txt. Read it with the command from Chapter 5.
prompt: admin@server1:~$ answer: cat timing/last-run.txt ||| cat ~/timing/last-run.txt ||| cat /home/admin/timing/last-run.txt output: INDEX REBUILD RECORD pages indexed: 128 terms written: 4096 hint: Section 16.6. The reading command from Chapter 5, then the path timing/last-run.txt, or ~/timing/last-run.txt from anywhere.
Three lines, the same three every time the program runs. Nothing in this file comes from the clock, which is why it can be quoted here at all.
The rebuild writes this file at its last step. The assessment checks that a file exists and that you read it; inspect its contents too, rather than
Practice Chapter 16. Time: date, sleep, time, watch, yes and seq in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.