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.

I did not realize that there was that much drift ...

Youre hardware clock is the one in the bios or Basic input output system of your computer that reflects the time in UTC or what some people cal zolo time which is then reflected by youre operating system as the local 12 hour time after the operating system applies the offset from UTC to the current time in your local timezone.

The "clock" in a PC computer generally is hardware. A register set used for nothing else, and it keeps time (poorly) based originally upon the refresh cycles for memory. Drift results because those cycles do not divide evenly into seconds or minut4es, so it provides only a rough approximation of human duration. This was the clock on the original PC.
Later a circuit design change allowed time to be saved to a register, and read and adjusted during IPL. Current boards have a Real Time Clock (RPC) that uses a very accurate oscillator and dedicated registers and is far more accurate, to the point that it can be used as a base to detect line power wave form variations (which is pretty good!).
What the operating system does with this hardware information is entirely software dependent. Originally DOS just asked you the date and time on startup, then incremented time based upon the inaccurate but dependable original hardware clock. Modern operating systems read the RTC, but (wisely, I believe) do not trust it and have provisions for alternate time sources either built in or available.
Windows machines that are members of a domain should pull their clock corrections from the domain controllers. This even works, if they are not too far off. If they are far off then authentication fail and they have to be clock corrected: it can be a pain.
Unix style operating systems have nothing built-in other than a fallback to RTC (like DOS did, but a bit better), but they all have NTP clients and servers available which are far superior. Rather than syncing clock to a domain server, NTP clients sync to an NTP server. NTP servers all sync to primary NTP servers, which are set by atomic clocks with far greater accuracy than is needed for any but the most demanding scientific purposes, or orbital mechanics and certain other very precise navigational purposes.
Don't we all LOVE overkill? ;-)

So when you say "clock" you are talking about at least two kinds of hardware clocks and possibly one or two software clocks, and possibly one or more clock sync standards. Under the covers it looks complex, because it "grew" that way and there is a lot of backward compatibility retained. Up front it is simple: hardware time (best set to CUT), software time (local time), and network OR NTP standard time (corrected CUT which the software and OS corrects to local). All so that you can look at your status bar instead of a wall clock, and your log files will have accurate time stamps for troubleshooting.

There is an advantage in understanding your software clock, the RELATION to hardware clock, and how to set/correct it for your OS. There is value in knowing how to set up your NTP clients to make sure your time is correct. There is probably little value to the average user in worrying about them beyond that. They work. MANY people spend effort making sure they work well, and without you having to worry about them. If you want to learn there is a TON of detail and additional information out there (including that behind the scenes NTP is really at least 6 sync protocols now: who cares, they all work), but it will all still work if you just set it once and forget about it as long as the OS/distribution maintainers did the job right. They generally DO the job right! ;-)

Don't we just have the best toys in the entire history of the human race?

CUT = UTC = Coordinated Universal Time for those that are still reading this thread...

The hardware clock is converted to UTC if set to local time which is used to set the system or software time. System time is always UTC regardless of timezone setting (remember the old 32 bit year 2038 rollover problem). Many of the desktops can have an independent taskbar timezone setting from the system timezone as well as display different timezone wall clocks.

I have read the high precision timer is not stable enough to be used as a wall clock so the time stamp counter is preferred now days. Time is complicated. "At the tone, the time will be ..."

Slight correction: depending upon who and what is setting it, the hardware clock CAN be set to local time AND PROVIDE ONLY LOCAL TIME), but never SHOULD be. The automated install on most Linux versions and all recent NTP setup sets UTC by default, but it has not always been so. And, someone with the knowledge of HOW and not enough understanding of WHY can still set it any way they like (often causing no END of problems!). IF it is set to local time and only provides that (never CUT) then things like daylight savings time changes go all wonky, as just one example.

All the hard work of the maintainers can be subverted by a clever users with a "brilliant plan" unless the enforcement is in hardware.

But what you describe is what happens if everyone does it right.