Difference between revisions of "Time"

From ArchWiki
Jump to: navigation, search
m (Other Details: - sp)
(Time Set)
Line 61: Line 61:
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):
  $ hwclock --show
  # hwclock --show
  $ date
  $ date

Revision as of 16:47, 10 December 2011

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary end

This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For maintaining accurate system time see Network Time Protocol.


The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the localtime standard, or the Coordinated Universal Time (UTC) standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current time zone, while UTC is the global time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether Daylight Saving Time (DST) is used.

The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an NTP program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon /etc/rc.d/hwclock uses hwclock to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in /etc/rc.conf).

When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).

Time Standard

You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:

$ grep ^HARDWARECLOCK /etc/rc.conf

The hardware clock can be queried and set with the hwclock command. To immediately change the hardware clock time standard to localtime use:

# hwclock --localtime

And to set it to UTC use:

# hwclock --utc

The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration (rc.conf) so that the system clock will be correctly set on boot:




Time Zone

Be sure that your time zone is set correctly in /etc/rc.conf. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:

$ grep ^TIMEZONE /etc/rc.conf

You can find the time zones listed in /usr/share/zoneinfo/ and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:


The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to /etc/localtime:

# cp /usr/share/zoneinfo/America/Chicago /etc/localtime

When you set the hardware clock the new time zone will be take used.

Time Set

The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):

# hwclock --show
$ date

To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):

# hwclock --set --date="YYYY-MM-DD hh:mm:ss"

To set the system clock:

# date MMDDhhmmYYYY

The hardware clock can be set from the system clock and vice versa:

# hwclock --systohc
# hwclock --hctosys

Time Skew

Every clock has a value that differs from real time (the best representation of which being International Atomic Time), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with hwclock the drift that has occurred is calculated in seconds per day (using the values of the previous drift and the last time time the hardware clock was set). If the hwclock has not been set within the previous 24 hours; hwclock overwrites the previous drift with the new drift in the file /var/lib/hwclock/adjtime. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour.

If the hardware clock keeps losing or gaining time in large increments, it is likely that an invalid drift is recorded. This can happen if you have set the hardware clock time incorrectly or your time standard is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file Template:Filename, then set the correct hardware clock and system clock time, and check if your time standard is correct.

The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using NTP. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.

UTC in Windows

Add the DWORD value:


with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to localtime. For these operating systems it is recommended to use localtime.

The hardware clock and system clock time may need to be updated after setting this value.

Other Details

  • 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.
  • If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.
  • The AUR application adjtimex can adjust kernel time variables like interupt frequency to help improve the system clock time drift.

It's About 'Time'

Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.

Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.

As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as International Atomic Time, or TAI.

The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.