If I do this $ timedatectl set-local-rtc 1 --adjust-system-clock
I get this
Warning: The system is now being configured to read the RTC time in the local time zone
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC
But the time is correct. with this
timedatectl set-local-rtc 0 --adjust-system-clock
the warning is not displayed but the time is off by two hours, where the right timezone is set.
How does the RTC get the proper time? Or what is the modern way to set the time proper.
In the SysVinit era, time was set with hwclock and either was fully supported.
Since systemd and timedatectl, only UTC is fully supported. They dropped write ot RTC completely.
If you’re dual booting with windows or don’t like this fact, you can still use local time in BIOS but remember to rewrite the RTC manually when time changes twice a year or let windows do that transparently.
Not quite correct. Both linux and windows use the time zone data and will adjust for DST automatically as long as they are allowed to do so in the system settings. AFAIK linux does it automatically but windows has a setting where the user can choose to allow or deny automatic adjustments.
I was given an edit to the windows registry that when run as administrator changes the behavior of windows to accept that RTC is in UTC and then behaves the same as linux. reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeUniversal /d /1 /t REG_DWORD /f
Note that you probably don’t want the --adjust-system-clock flag if your PC is displaying the time correctly before you switch. In this context “system clock” is the one the kernel is running and being used to display the time within Linux, and RTC is the chip on your PCs motherboard.
Running timedatectl set-local-rtc With the flag, your system clock is reconfigured from the RTC after changing the settings - so if the RTC was set to your local time and you then start treating it as UTC your system clock will end up being X hours out.
Without the flag, the RTC will be treated as UTC and updated to the UTC time equivalent to your current system clock. I suspect this is what you wanted.
So once the time is correctly displayed (either by timedatectl, date, or just on your desktop), you should just need to run timedatectl set-local-rtc 0 on its own to keep the RTC in UTC.
Coming back to your original question:
On most (all?) default installations, chrony should be installed and running and it will periodically keep the RTC updated so you shouldn’t need to sync it manually. If you ever do need to poke it manually, the command you probably want to look up is hwclock
That is a time jump of 2 hours (more or less), which was caused by the --adjust-system-clock option you were using. Reading from man timedatectl
set-local-rtc [BOOL]
Takes a boolean argument. If "0", the system is configured to
maintain the RTC in universal time. If "1", it will maintain the RTC
in local time instead. Note that maintaining the RTC in the local
timezone is not fully supported and will create various problems
with time zone changes and daylight saving adjustments. If at all
possible, keep the RTC in UTC mode. Note that invoking this will
also synchronize the RTC from the system clock, unless
--adjust-system-clock is passed (see above). This command will
change the 3rd line of /etc/adjtime, as documented in hwclock(8).
In other words:
without --adjust-system-clock RTC is synced from the system clock
with --adjust-system-clock the system clock is synced from the RTC
As the system clock was correct, you need to sync RTC from the system clock to avoid the time jump.
$timedatectl status
Local time: Wed 2026-06-03 20:15:15 CEST
Universal time: Wed 2026-06-03 18:15:15 UTC
RTC time: Wed 2026-06-03 18:15:15
Time zone: Europe/Zurich (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
They are the ntp timesync servers that chronyc is using to correct your local time for clock drift.
Have a look at chronyc tracking to see how much drift your machine has. Chronyc will slow tweak the clock to correct for drift over a relatively long timer period so that you don’t get any massive 2 hour jumps as you saw a few days ago.
But the only timeserver I want it to use is my LAN gateway (_gateway) as it sets the time to all equipment in my LAN even the windows machines. And this is the only one my dhcp server hands out.
sudo nmap --script broadcast-dhcp-discover
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 3:
| Interface: wlp0s20f3
| IP Offered: 192.168.111.34
| DHCP Message Type: DHCPOFFER
| Subnet Mask: 255.255.255.192
| Router: 192.168.111.30
| Domain Name Server: 192.168.111.2
| Domain Name: kingma
| Broadcast Address: 192.168.111.63
| NTP Servers: 192.168.111.30
| IP Address Lease Time: 1d12h00m00s
| Server Identifier: 192.168.111.2
| Renewal Time Value: 18h00m00s
| Rebinding Time Value: 1d07h30m00s
Ok - weird requirement - you’re almost guaranteed to end up with the incorrect time on your machines but they’re your machines so you can do what you like with them
You’ll need to remove the ntp pool from /etc/chrony.conf. It’s probably joining the fedora ntp pool by default.
But yes, you made me think that on my Laptop I should add a known ntp here in switzerland (metas.ch, for which I pay taxes in CH)) or go with with a ch.ntp.pool.org (wich my gateway happens to be part of)
# These servers were defined in the installation:
pool ch.pool.ntp.org iburst
But the dhcp server advertises my gateway. So to me still a mystery where these others come from. Apart from the fact that they are extremely off. Where my own time keeping at gateway is perfect:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp11.metas.ch .PZF. 1 u 44 64 377 13.492 -0.219 0.278
+ntp12.metas.ch .PZF. 1 u 21 64 377 13.704 0.054 0.291
*ntp13.metas.ch .PZF. 1 u 57 64 377 13.679 -0.127 0.255
