13.3. Showing and setting time

In the Debian system, the system time zone is determined by the symbolic link /etc/localtime. This link points at a time zone data file that describes the local time zone. The time zone data files are stored in /usr/lib/zoneinfo. Other Linux distributions may do this differently.

A user can change his private time zone by setting the TZ environment variable. If it is unset, the system time zone is assumed. The syntax of the TZ variable is described in the tzset manual page.

The date command shows the current date and time. [1] For example:

$ date Sun Jul 14 21:53:41 EET DST 1996 $

That time is Sunday, 14th of July, 1996, at about ten before ten at the evening, in the time zone called ``EET DST'' (which might be East European Daylight Savings Time). date can also show the universal time:

$ date -u Sun Jul 14 18:53:42 UTC 1996 Sun Jul 14 18:53:42 UTC 1996 $

date is also used to set the kernel's software clock:

# date 07142157 Sun Jul 14 21:57:00 EET DST 1996 # date Sun Jul 14 21:57:02 EET DST 1996 #

See the date manual page for more details; the syntax is a bit arcane. Only root can set the time. While each user can have his own time zone, the clock is the same for everyone.

date only shows or sets the software clock. The clock commands synchronises the hardware and software clocks. It is used when the system boots, to read the hardware clock and set the software clock. If you need to set both clocks, you first set the software clock with date, and then the hardware clock with clock -w.

The -u option to clock tells it that the hardware clock is in universal time. You must use the -u option correctly. If you don't, your computer will be quite confused about what the time is.

The clocks should be changed with care. Many parts of a Unix system require the clocks to work correctly. For example, the cron daemon runs commands periodically. If you change the clock, it can be confused of whether it needs to run the commands or not. On one early Unix system, someone set the clock twenty years into the future, and cron wanted to run all the periodic commands for twenty years all at once. Current versions of cron can handle this correctly, but you should still be careful. Big jumps or backward jumps are more dangerous than smaller or forward ones.