From ArchWiki
Revision as of 07:05, 15 October 2011 by Argh! (talk | contribs) (About)
Jump to: navigation, search

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 to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see Network Time Protocol.


The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the localtime standard or the Coordinated Universal Time (UTC) standard (also known as GMT, though conceptually different). Localtime is dependent on your local time zone while UTC is global time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether Daylight Saving Time (DST) is used.

All the most common operating systems can be told to use either UTC or localtime. By default, UNIX-like operating systems (including Mac OS) will generally set the hardware clock to UTC, while Windows operating system will use localtime. When dual booting with other operating systems it is best to set all of them to use UTC to avoid clocks becoming incorrect when switching back and forth between each other.

In UNIX-like systems, the hardware clock can be queried and set with the Template:Codeline command.

Linux also has a software clock (a.k.a. the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses DST. Arch Linux's daemon Template:Filename (which makes use of the Template:Codeline command) sets the system clock from the hardware clock at start (e.g. on boot), and sets the hardware clock from the system clock when stopped (e.g. on shutdown): users must include 'hwclock' in the DAEMONS list in Template:Filename for this to happen automatically. As an alternative to using the hwclock daemon, users often use NTP to keep the system clock set to the proper time.

Note: In other words: If using UTC, the hardware clock (BIOS / the computer) will be set to a "wrong" time: without offset of your timezone nor DST (eg. GMT +0h / London Time without DST). The system clock (the operating system) will adjust time using the timezone you specify. If using localtime (discouraged), the system clock will just use the hardware clock unchanged, and adjustments for DST have to be made manually.

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

To immediately change the hardware clock time standard, you can set localtime by:

# hwclock --localtime

And to set it as UTC by:

# 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 at restart (if the hwclock script is used):



Note: GNU/Linux will change to-and-from DST when the Template:Codeline setting is set to Template:Codeline, regardless of whether GNU/Linux was running at the time DST is entered or left. When the Template:Codeline setting is set to Template:Codeline, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.

Your hardware clock and system clock time may need to be updated after this, read #Time Set.

Time Zone

Be sure that your time zone is set correctly in Template:Filename, this not only is necessary 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 Template:Filename 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 it or copy it to Template:Filename:

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

When you set the hardware clock in the next step the new time zone will be 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:

$ hwclock --show
$ date

To set the hardware clock directly (in military time):

# hwclock --set --date "MM/DD/YYYY 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

No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being International Atomic Time). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with Template:Codeline (e.g. during shutdown), Template:Codeline uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; Template:Codeline overwrites the previous drift with the new drift in the file Template:Filename. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you see that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in Template:Filename. 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. To fix this remove Template:Filename, set the correct hardware clock and system clock time, and check if your time standard is correct.

Note: If you always power down your PC more often than once a day, the drift in the Template:Filename will never be recalibrated (after the initial value was written) as each shutdown (Template:Codeline set) will occur more often than once every 24 hours. It may be worth occasionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronized to real time just before shutdown.

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 will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the Template:Codeline application (from the AUR).

Note: If you do not use NTP and your hardware clock is more accurate than your system clock, then setting the hardware clock from system clock with Template:Filename will cause your hardware clock to become less accurate; in this case you need to modify Template:Filename not to do this, by commenting out the call to Template:Codeline in the stop case.