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
hwclock to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in
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).
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:
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
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime
When you set the hardware clock the new time zone will be take used.
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
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
The hardware clock and system clock time may need to be updated after setting this value.
- 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
adjtimexcan 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.