---

   hwclock    ( 8 )

---

DATE-TIME CONFIGURATION

Keeping Time without External Synchronization This discussion is based on the following conditions:

• Nothing is running that alters the date-time clocks, such as NTP daemon or a cron job."

• The system timezone is configured for the correct local time. See below, under POSIX vs 'RIGHT'.

• Early during startup the following are called, in this order: adjtimex --tick value --frequency value hwclock --hctosys

• During shutdown the following is called: hwclock --systohc

• Systems without adjtimex may use ntptime.

Whether maintaining precision time with NTP daemon or not, it makes sense to configure the system to keep reasonably good date-time on its own.

The first step in making that happen is having a clear understanding of the big picture. There are two completely separate hardware devices running at their own speed and drifting away from the 'correct' time at their own rates. The methods and software for drift correction are different for each of them. However, most systems are configured to exchange values between these two clocks at startup and shutdown. Now the individual device's time keeping errors are transferred back and forth between each other. Attempt to configure drift correction for only one of them, and the other's drift will be overlaid upon it.

This problem can be avoided when configuring drift correction for the System Clock by simply not shutting down the machine. This, plus the fact that all of hwclock's precision (including calculating drift factors) depends upon the System Clock's rate being correct, means that configuration of the System Clock should be done first.

The System Clock drift is corrected with the adjtimex(8) command's --tick and --frequency options. These two work together: tick is the coarse adjustment and frequency is the fine adjustment. (For systems that do not have an adjtimex package, ntptime -f ppm may be used instead.)

Some Linux distributions attempt to automatically calculate the System Clock drift with adjtimex's compare operation. Trying to correct one drifting clock by using another drifting clock as a reference is akin to a dog trying to catch its own tail. Success may happen eventually, but great effort and frustration will likely precede it. This automation may yield an improvement over no configuration, but expecting optimum results would be in error. A better choice for manual configuration would be adjtimex's --log options.

It may be more effective to simply track the System Clock drift with sntp, or date -Ins and a precision timepiece, and then calculate the correction manually.

After setting the tick and frequency values, continue to test and refine the adjustments until the System Clock keeps good time. See adjtimex(2) for more information and the example demonstrating manual drift calculations.

Once the System Clock is ticking smoothly, move on to the Hardware Clock.

As a rule, cold drift will work best for most use cases. This should be true even for 24/7 machines whose normal downtime consists of a reboot. In that case the drift factor value makes little difference. But on the rare occasion that the machine is shut down for an extended period, then cold drift should yield better results.

Steps to calculate cold drift:

1 Ensure that NTP daemon will not be launched at startup.

2 The System Clock time must be correct at shutdown!

3 Shut down the system.

4 Let an extended period pass without changing the Hardware Clock.

5 Start the system.

6 Immediately use hwclock to set the correct time, adding the --update-drift option.

Note: if step 6 uses --systohc, then the System Clock must be set correctly (step 6a) just before doing so.

Having hwclock calculate the drift factor is a good starting point, but for optimal results it will likely need to be adjusted by directly editing the /etc/adjtime file. Continue to test and refine the drift factor until the Hardware Clock is corrected properly at startup. To check this, first make sure that the System Time is correct before shutdown and then use sntp, or date -Ins and a precision timepiece, immediately after startup.

LOCAL vs UTC Keeping the Hardware Clock in a local timescale causes inconsistent daylight saving time results:

• If Linux is running during a daylight saving time change, the time written to the Hardware Clock will be adjusted for the change.

• If Linux is NOT running during a daylight saving time change, the time read from the Hardware Clock will NOT be adjusted for the change.

The Hardware Clock on an ISA compatible system keeps only a date and time, it has no concept of timezone nor daylight saving. Therefore, when hwclock is told that it is in local time, it assumes it is in the 'correct' local time and makes no adjustments to the time read from it.

Linux handles daylight saving time changes transparently only when the Hardware Clock is kept in the UTC timescale. Doing so is made easy for system administrators as hwclock uses local time for its output and as the argument to the --date option.

POSIX systems, like Linux, are designed to have the System Clock operate in the UTC timescale. The Hardware Clock's purpose is to initialize the System Clock, so also keeping it in UTC makes sense.

Linux does, however, attempt to accommodate the Hardware Clock being in the local timescale. This is primarily for dual-booting with older versions of MS Windows. From Windows 7 on, the RealTimeIsUniversal registry key is supposed to be working properly so that its Hardware Clock can be kept in UTC.

POSIX vs 'RIGHT' A discussion on date-time configuration would be incomplete without addressing timezones, this is mostly well covered by tzset(3). One area that seems to have no documentation is the 'right' directory of the Time Zone Database, sometimes called tz or zoneinfo.

There are two separate databases in the zoneinfo system, posix and 'right'. 'Right' (now named zoneinfo-leaps) includes leap seconds and posix does not. To use the 'right' database the System Clock must be set to (UTC + leap seconds), which is equivalent to (TAI - 10). This allows calculating the exact number of seconds between two dates that cross a leap second epoch. The System Clock is then converted to the correct civil time, including UTC, by using the 'right' timezone files which subtract the leap seconds. Note: this configuration is considered experimental and is known to have issues.

To configure a system to use a particular database all of the files located in its directory must be copied to the root of /usr/share/zoneinfo. Files are never used directly from the posix or 'right' subdirectories, e.g., TZ='right/Europe/Dublin'. This habit was becoming so common that the upstream zoneinfo project restructured the system's file tree by moving the posix and 'right' subdirectories out of the zoneinfo directory and into sibling directories:

/usr/share/zoneinfo, /usr/share/zoneinfo-posix, /usr/share/zoneinfo-leaps

Unfortunately, some Linux distributions are changing it back to the old tree structure in their packages. So the problem of system administrators reaching into the 'right' subdirectory persists. This causes the system timezone to be configured to include leap seconds while the zoneinfo database is still configured to exclude them. Then when an application such as a World Clock needs the South_Pole timezone file; or an email MTA, or hwclock needs the UTC timezone file; they fetch it from the root of /usr/share/zoneinfo , because that is what they are supposed to do. Those files exclude leap seconds, but the System Clock now includes them, causing an incorrect time conversion.

Attempting to mix and match files from these separate databases will not work, because they each require the System Clock to use a different timescale. The zoneinfo database must be configured to use either posix or 'right', as described above, or by assigning a database path to the TZDIR environment variable.