14.3. Showing and setting time

In Linux, the system time zone is determined by the symbolic link /etc/localtime. This link points to a time zone data file that describes the local time zone. The time zone data files are located at either /usr/lib/zoneinfo or /usr/share/zoneinfo depending on what distribution of Linux you use.

For example, on a SuSE system located in New Jersey the /etc/localtime link would point to /usr/share/zoneinfo/US/Eastern. On a Debian system the /etc/localtime link would point to /usr/lib/zoneinfo/US/Eastern.

If you fail to find the zoneinfo directory in either the /usr/lib or /usr/share directories, either do a find /usr -print | grep zoneinfo or consult your distribution's documentation.

What happens when you have a users located in a different timezone? 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.

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

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

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

Beware of the time command. This is not used to get the system time. Instead it's used to time how long something takes. Refer the the time man page.

date only shows or sets the software clock. The clock commands synchronizes 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.