Confusion on how time works in Linux?
 

I pulled this from the Sanders RHCSA book on NTP and wanted to verify some things about time in Linux:




I'm running into an issue where time isn't being set correctly
If hardware time is the SAME as RTC, why aren't the times the same?


I run:
date: used to manage SYSTEM time:
Fri Aug 5 15:25:38 EDT 2022

hwclock --show: used to manage HARDWARE time:
Fri 05 Aug 2022 03:25:41 PM EDT

Timedatectl: used to manage all aspects of time:
RTC time: Fri 2022-05-05 19:25:56


RTC time is COMPLETELY different than what hardware clock shows?

Also why is the time off when I set the time for the system time to be the same as hardware time? It's off by a couple milli-seconds? Will I get points off on the test for that?



Are these definitions accurate?












Hardware clock:
"The hardware clock that resides on the main card of a computer system"

Real-time clock (RTC):
Same as the hardware clock

System time:
The time that is maintained by the operating system

Software clock:
Similar to system time

Coordinated Universal Time (UTC):
A worldwide universal standard time

Daylight saving time (DST):
"Calculation that is made to change time automatically when DST changes occur"

Local time
"The time that corresponds to the time in the current time zone"

Your RTC is set to Coordinated Universal Time (or UTC Standard time). The kernel and user space programs adjust the display of time to your local time zone and numeric display settings. The current offset between Eastern USA Time Zone and UTC is four hours, thus the numbers you reported. By using UTC in hardware and internally several nasty bugs that plagued system administrators, programmers, and network engineers back in the dark ages of computing become irrelevant or easy to deal with.

What you see is a solution, not a problem.

Ok so the RTC is set to UTC. Which one is the real hardware clock time then? The output of hwclock or RTC time?

UTC = EDT + 4 hours.
19:25 UTC = 03:25 PM EDT = 15:25 EDT + 4 (UTC offset)

RTC time as seen in bios is set at UTC. The system then sets the local time zone and displays time locally.

I think all OSes follow this paradigm and have for many many years

You can easily find the current UTC time by searching online for UTC time.

It depends. You can use either local or UTC (UTC being preferred) and the clock setting in the /etc/adjtime file tells the system how the RTC is configured.

True.
Maybe I should have said "normally" or "by default" since I have never needed to change that file for as long as linux has existed.

If RTC is not set to UTC then the user has to know how much it is offset, change the value in the /etc/adjtime file accordingly, and still set the time zone properly in order for the display to be correct.

Every PC or laptop I have purchased for the past 20 years has already had UTC set in the RTC and the only thing the user is required to do is set the time zone.

On my (Manjaro) system timectl gives you the full picture:

If you want to see what is actually on your hardware clock, you must run hwclock with the --debug option. You will then see both the actual hardware clock time and the equivalent local time. Otherwise you see local time only.

Thanks for sharing this. I tried it out and found that the --debug option has been deprecated and the system recommends that you use --verbose instead.

A couple of explanations.

The practice of using UTC internally goes back to the days when the only computers are mainframes. Many firms wanted to computerise payroll or whatever but couldn't afford a machine, so they bought time from a company and communicated with that computer over a phone line. In the USA that could mean that they were on opposite sides of a time boundary and they might also differ over whether they used daylight-saving. Using UTC meant that files were safely time-stamped.

The first PC's didn't have battery-backed clocks. I remember my IBM PC back in 1981 — when you switched it on, the first thing it did was to ask you to set the date and time, and obviously you read the local time off your clock or watch. It didn't matter what that time was, since the computer wouldn't be talking to another one — it was supposed to be personal, after all. Windows still uses local time by default.

The reason why the internal time is reported as local is so that you can easily check that your clock is OK by just asking, without having to perform any mental arithmetic or even knowing your zone.

Info:
https://wiki.archlinux.org/title/System_time

That takes me back! The first PC that I saw at work (it was a Compaq) started up exactly like that. The first time I saw a computer start up and set its own date absolutely amazed me.

Most computers periodically run a daemon process, "ntp," which periodically queries an "internet time server" which is governed by a very expensive atomic clock. They rely upon the accuracy of the built-in quartz controlled clock until it is time to resync again, so as not to place too much burden on these servers. All modern operating systems do this, so far as I know.

Time servers are available all around the world. There is also a console command which can synchronize the clock anytime you like, from any server you choose, but it is normally not necessary to do this. Your system's clock, once correctly set, remains extremely accurate. Motherboards use batteries to keep the clock running even when the board is turned off.

Time zone information is kept in the tzinfo file, and that file is actually quite interesting. It preserves, not only how things like "daylight savings time" is, but how it was. So, if you submit a UTC time for conversion that is very old, the conversion should still correctly reflect the time-zone rules that were in effect at that time and place (zone).

You can also obtain "perfect time" from a GPS device, since this also relies on atomic time as the fundamental aspect of how the whole thing actually works. Your cell phone probably obtains its time from the cell provider, who should also be referencing an atomic (network time) source.

Time values in a database should always be stored as UTC, and they normally are. Values stored in this way are "good anywhere," without ambiguity. When you query the database, the values are reported to you in the time-zone that you have set up for your computer (your "locale ..."), unless you specify otherwise.

The system and software clock are the same thing.

The hardware clock on modern PCs is builtin to whatever they call the southbridge chip these days and uses a quartz crystal oscillator. Depending on the quality i.e. cost, the oscillators in PC's typically have an accuracy of anywhere form 20 - 100 PPM now days. This correlates between ~ 2-9 seconds of drift per day and this can change as the crystal ages. The hardware clock is basically used to set the system clock at start up. The battery keeps the hardware clock running when power is off.

The system clock basically runs off the clock generator that runs the CPU. Now days its a 64 bit counter that measures the number of seconds with zero being January 1, 1970 midnight(0000) UTC. System clock drift can be due to lots of factors.

ntp will measure the system clock drift and automatically determine the best rate to poll the servers to keep it in sync. The default settings are anywhere from 10-1024 seconds. After an initial time set at boot up it will slowly skew time versus a jump if the difference is small.

UTC time is based on the weighted average of around 300 atomic reference clocks located around the world called international atomic time. Basically UTC is atomic time adjusted for leap seconds. The master NTP servers are startum 0, the servers that sync to them are stratum 1 and so on. The purpose of pools is to balance the load.