0

Scenario:

  • a Dell R740 server for example whose BIOS clock is first set, and it is set to UTC time but incorrectly and it is off 30 minutes. Then, a clean installation of Linux is performed (Redhat-8.10) and during installation the timezone is chosen, New York so EST. After installation, the time as presented in Linux via date is the correct local time but off 30 minutes, if we reference a peek at time.gov for correct time. There is no network connection to this server and no NTP/chrony is set up.

  • My observation is, if I manually adjust time to be correct (referencing time.gov from a different computer or my phone) by doing date mmddhhmm and then reboot, Linux reads the BIOS clock and then after booting the time in Linux is off 30 minutes again.

  • On my home computer which has an asrock motherboard and 2 different SSD's one for win10 the other for RHEL-8.10 Linux, and an internet connection, my BIOS clock is set to local time and I use win10 most of the time (and windows had NTP active). On the times I boot Linux, the time in Linux is the correct local time as presented by date however when I shutdown and then run windows the time in windows is then off by 4 or 5 hours; I am EST/EDT timezone.

Also:

Windows expects the hardware clock to give “local time” by default. The reason is, according to Microsoft, so that users are not confused in BIOS menu; this is from a github page statement. Getting Windows to recognize BIOS (real-time-clock) as UTC apparently requires "tweaking"

  • What is the deal with how Linux deals with the BIOS clock?
  • Am I expected to use hwclock <--systohc | --hctosys> ?
  • What's the proper convention regarding what the BIOS clock is set to, UTC or local?
    • I seem to experience two different behaviors of Linux where it assumes on a Dell {enterprise style} server that the BIOS clock is UTC but on my cheap home asrock it is set to local time; And playing at home setting my asrock bios clock to UTC causes way more problems.
  • What are files in Linux dealing with this, to understand what Linux is going to do regarding time? Does it always reference the BIOS clock upon boot, and where is it specified in Linux for what timezone it should assume the BIOS clock to be in?
Improve this question
1

2 Answers 2

Reset to default
2
  • What is the deal with how Linux deals with the BIOS clock?

Consistently. Even if Windows does it, it makes no sense to set the RTC (that's what you mean when you say "BIOS clock") to local time. Otherwise, you'd need to know whether a daylight savings switch, leap second, or travel to another timezone happened while a computer was off. Which is logically impossible to do, if you don't tell every operating system you run to write the shutdown time to a special place on disk and every operating system to first check that place to check whether something should have happened to the RTC while the computer was off. (and that place does not exist, so, this is impossible.)

Correct automatic power-on schedule setting before a DST transition wouldn't be logically possible at all, because you can't know whether you'll boot before, and so on. RTC in local time is just a really bad idea.

So, Linux is not the strange thing here. By default, the Linux kernel and the userland assumes RTCs to be universal time.

  • Am I expected to use hwclock <--systohc | --hctosys> ?

No.

  • What's the proper convention regarding what the BIOS clock is set to, UTC or local?

UTC.

I seem to experience two different behaviors of Linux where it assumes on a Dell {enterprise style} server that the BIOS clock is UTC but on my cheap home asrock it is set to local time; And playing at home setting my asrock bios clock to UTC causes way more problems.

Cannot confirm that, and it's not how this generally works. You can tell your system to interpret your RTC as being in local time, or in universal time; check man timedatectl, section set-local-rtc. It specifically warns you about the idea to keep the RTC in local time. It's not supported, and it brings a host of problems.

Does it always reference the BIOS clock upon boot,

Where but the RTC would an operating system on an offline computer take the time from at boot, if not the RTC? yes.

and where is it specified in Linux for what timezone it should assume the BIOS clock to be in?

Linux (the kernel) itself assumes UTC.

As mentioned above, you can "kind of try to trick the software system" into correcting that assumption if you really want to set your RTC to a different time zone. But that just lets Linux boot, set an incorrect system time under the assumption that RTC is in UTC, then a service is started, says, "nonono, you need to adjust the system clock by X hours, we're doing this strange thing with RTC in local time", and adjusts the system clock.

The default local time zone is stored as symlink, readlink /etc/localtime.

Improve this answer
6
  • question: if Linux does use NTP/chrony for accurate local time, then upon a clean Linux shutdown/reboot does it modify/update the BIOS (RTC) ? Or is it a merry go round where the RTC is off so Linux always boots and runs with incorrect time until it corrects itself via NTP, and this happens after every boot ? Commented Apr 30 at 15:20
  • is there a Linux setting such that "I see ntp/chrony is in use and tracking is good, therefore update the RTC upon shutdown (to UTC time) so the RTC clock is correct? Or does a custom systemd service need to be written for that to do a hwclock --systohc ? Commented Apr 30 at 15:22
  • this depends on which NTP client you're using. Generally, such clients can run in one-shot or daemon modes, and they will tell the Linux kernel to adjust the hardware time (whatever shape that takes) either as a "one-off" thing immediately, or over time tell it to adjust the system clock, by saying it should experience a frequency adjustment. Typical kernel driver settings are then to update the RTC from that every minute or every five minutes of operations. "Linux" is not precise enough here, you really need to look at what NTP synchronization client in which configuration you use. Commented Apr 30 at 15:39
  • And as I already said in my answer: stop thinking about hwclock. Not your tool here, nobody expects anyone to use something as crude as that. Commented Apr 30 at 15:39
  • "Where but the RTC would an operating system on an offline computer take the time from at boot, if not the RTC?" ... IIRC systemd now has a fallback - if an RTC is not available or the RTC reports time too far in the past, I think it forces system time to its build timestamp. Commented Apr 30 at 15:54
0

in testing (and searching)

  • https://man7.org/linux/man-pages/man4/rtc.4.html
  • When the kernel's system time is synchronized with an external reference using adjtimex(2) it will update a designated RTC periodically every 11 minutes. To do so, the kernel has to briefly turn off periodic interrupts; this might affect programs using that RTC.
    • I do not know if chronyd needs to be running for this to happen, per rtcsync in /etc/chrony.conf
  • The BIOS clock can get updated upon Linux shutdown as I have observed; this is good if you set system time by whatever method to be correct then it should update the BIOS clock so that next time the system boots the time is correct. However I did observe instances where it did not get updated and was off by the 20 minutes I had specifically set it to be off in which case the system boots and has incorrect time and while going forward if the BIOS clock stays on track and doesn't skew then everytime you reboot your system time is off until it gets corrected. This is a problem in an isolated environment with no internet and no good/real time server.
  • /etc/adjtime in Linux is where UTC is specified (or LOCAL) for knowing what timezone the RTC is assumed to be in; I assume LOCAL then references `/etc/localtime

The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. The util hwclock(8) keeps the file /etc/adjtime, that keeps some historical information. For more details see "The Adjust Function" and "The Adjtime File" sections from hwclock(8) man page.

/etc/adjtime is to contain the drift factor and last adjust time of the hardware clock

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.