In an operating system, clock is determined by four parts: Time value, Time standard, Time Zone, and Daylight Saving Time (DST) if applicable. This article explains what they are and how to read and set them. For maintaining accurate system time see Network Time Protocol.
Hardware clock and system clock
There are two clocks to keep track of: "hardware clock" and "System clock".
Hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used.
System clock (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It 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, dependent on the value of the HARDWARECLOCK defined in
/etc/rc.conf. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.
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.
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 system clock directly:
# date MMDDhhmmYYYY
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"
The hardware clock can be set from the system clock and vice versa:
# hwclock --systohc # hwclock --hctosys
Standard behavior of most operating systems is:
- Set the system clock from the hardware clock on boot
- Keep accurate time of the system clock with an NTP daemon
- Set the hardware clock from the system clock on shutdown.
In Arch Linux, the
/etc/rc.d/hwclock daemon uses
hwclock to set the system and hardware clocks on boot and shutdown if
hwclock is in the
DAEMONS list in
/etc/rc.conf). Running the
hwclock daemon is not recommended if running the NTP daemon as the NTP daemon also adjusts the hardware clock.
There are two time standards: localtime and Coordinated Universal Time (UTC). The localtime standard is dependent on the current time zone, while UTC is the global time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT.
The standard used by hardware clock is defined by operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary.
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 occurrences 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:
During kernel startup, at the point when the rtc driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of
/proc/sys/class/rtcN/hctosys (N=0,1,2,..) will be set to 1. Later during execution of
/etc/rc.sysinit, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards which is always a bad idea.
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.
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 used. This means that your hardware clock (on the motherboard) if viewed through the BIOS will be showing GMT (Standard Time).
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, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file
/var/lib/hwclock/adjtime overwriting the previous values. The hardware clock can be adjusted for drift when the command
hwclock --adjust is run; this occurs by default on shutdown if the
hwclock daemon is enabled.
hwclockconsiders the elapsed time period too short to accurately calculate the drift. It may be worth occasionally to stay in Linux so it gets calculated
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been 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
/var/lib/hwclock/adjtime, then set the correct hardware clock and system clock time, and check if your time standard is correct.
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. There are some tools to improve software clock accuracy:
- NTP can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.
- AUR can adjust kernel time variables like interrupt frequency to help improve the system clock time drift. AUR in
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 led 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.