System time off 8 hours
 

This is a new system with two recent Slackware64-current installs -One with Plasma5/KDE5 and the other with KDE4. Both are exhibiting the same behavior where after boot the system time is 8 hours behind from my timezone PST. It doesn't matter if I try to set system for automatic (read from pool.ntp.org) or not (read from system bios???). Clock in Bios is correct (matches US/Pacific). How to fix this so that I don't have to manually set system time after reboot?

Run timeconfig.

FYI, 8 hrs is the diff between UTC and PST. The date command would show UTC before you change it.

In addition, the /etc/adjtime file is the reference for the hardware clock. UTC = UTC or LOCAL if it is set for local time as in your case. The default is UTC.

If you are not dual booting the preference is UTC.

This is worse than I thought. The act of 'booting' in either of these -current installs is writing a time (8 hours behind PST) to the BIOS! This is really bad! The OS should not be writing the system BIOS!

The usual process is the OS reads the hardware clock to set the system time at boot and writes the system time to the hardware clock at shutdown.

Its not bad, the hardware clock is separate from BIOS configuration settings. Again make sure the settings i.e. /etc/adjtime are the same for both.

Worse still is the fact there is no place in the world that this time is True. Relative to UTC is -16 hours. The legitimate spread is -12 to +12.

michaelk - I guess I wrongly assumed the hardware clock was the same as the BIOS. How and where does one set the "hardware clock"? Windows (also installed on this system) has no issue booting into the clock set in BIOS. Neither does a liveslack USB (DVD).

time fix
 

as root I run:

... wait for 20 seconds and the desktop should update (in other words: it doesn't happen immediately).

I have a new Asus H470-CSM motherboard that I need to figure out all the parameters and my time is always off. I don't need the complexity and I should have bought a Gigabyte (much easier to configure).

Regardless the above command fixes the time without a hitch.

You can set the hardware clock from the system using the hwclock command.

Basically when the computer starts the boot process reads the hardware clock to set the system clock. If the /etc/adjtime is set to LOCAL the time is converted to UTC first then the clock is set. If the clock is local as posted but the OS thinks it is UTC or vice versa the system clock will be different by the UTC offset for your time zone i.e. 8 hours. The hardware clock is updated when the system shutdowns also based on the adjtime configuration. If running two different OSs that are configured differently the clock could be off by multiple offset factors like 16 hours.

Have you looked at your /etc/adjtime file for both operating systems yet? Typically Windows uses local time as a reference for the hardware clock by default but it also will automatically use an internet time source to correct itself. Although switching between Windows and Linux might mess itself up evidentially until an update.

Syncing your system clock with an internet time source will force the clock to the correct time regardless of the hardware clock setting. netdate and ntpdate are one time corrections unless you run a cron job, ntp will update the system clock continuously.

What sometimes makes matters worse is the desktop clock which typically is configured for the configured timezone may not be and so the date command and the desktop can also display different times which is also confusing.

Ok this took way too much time and I am still not happy with the outcome. Something is rotten and I'm not sure how to fix this. It seems the two s*64-current installations want the BIOS to be set at UTC and Windows wants the BIOS to be set at Local PST time. Since I rarely boot Windows I will live with the time being set 8 hours ahead in BIOS and be cognizant that it is 8 hours ahead in Windows.

I have the hwclock set to the correct local PST time now. It was set at PST - 8 hours when all this trouble started. Now when I reboot both Slackware systems they are consistently coming up at the correct local PST time. I've learned in this process there is a whole other clock and that the kernel keeps track of.

This is way more complicated than I thought. It took several reboots and configuring things to get it right. At one point I tried putting matux's suggested correction in /etc/rc.d/rc.local
if [ -x /usr/sbin/netdate ]; Then
netdate time.nist.gov
fi

but this broke things too.
This is relatively new hardware so something could also be buggy with the BIOS.
Motherboard: MSI MPG X570 Gaming Edge WIFI

Sorry for the handle typo above maltux. Thanks for the inputs from all.

When dual booting Linux and Windows, I usually just force Windows to assume that the hardware clock is set to UTC instead of local time (here's how to do it). That way, both OS will assume that the hardware clock is set to UTC and no weird clock issues will happen when changing OSes.

FYI netdate uses the RFC-868 time protocol which only has a resolution of 1 sec and does not have very good error handling. According to NIST only 1% of the internet uses RFC-868 anymore as compared to ntp. ntpdate uses ntp which has a resolution of 200 ps. ntp is deprecated but ntp has the same functionality using the -g option.

Ah, well. If that information had been shared in the first post the problem would have been resolved in one reply. :)

mumahendras3 shared how to fix the problem in the Windows registry.

Hopefully the problem is now resolved!