Today, when I started my laptop, the time was initially wrong. It ran datetimectl which issue a warning about RTC in local TZ: yes so I changed it to no and the time seemed to correct itself. However, I noticed that time in the output of datetimectl the RTC time was not the UTC time but the local time. Which led me to issue
this brought RTC and UTC in alignment but brought back the problem with local time being incorrect and also led to (correct) complaints from chrony that time is incorrect.
So I tried manually setting the time. This led to the following:
~ ❯ sudo timedatectl set-ntp no
~ ❯ sudo timedatectl set-time 10:47
~ ❯ sudo timedatectl set-ntp yes
~ ❯ timedatectl status
Local time: Tue 2024-08-27 10:47:09 PKT
Universal time: Tue 2024-08-27 05:47:09 UTC
RTC time: Tue 2024-08-27 05:47:09
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
~ ❯ timedatectl status
Local time: Tue 2024-08-27 10:49:09 PKT
Universal time: Tue 2024-08-27 05:49:09 UTC
RTC time: Tue 2024-08-27 10:49:09
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Basically, I turned off ntp, changed to time to correct and then turned on ntp. As you can see when system clock was not synchronized RTC time was UTC however after synchronization, RTC time changed to local time.
Does someone understand what is happening? At this stage what datetimectl report seems inconsistent.
I’m not sure on the difference with timedatectl set-local-rtc --adjust-system-clock 0 but here’s what I used to do:
sudo timedatectl set-local-rtc '0'
And verify:
timedatectl | grep local
To get:
RTC in local TZ: no
With timedatectl reporting:
Local time: Tue 2024-08-27 13:04:12 EDT
Universal time: Tue 2024-08-27 17:04:12 UTC
RTC time: Tue 2024-08-27 17:04:11
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
I only needed to mess with that if I dual-booted Windows and Fedora happened to see it before installing it (later dual-boots I’d just temp-remove the Windows drive and later set Windows to UTC)
Basically, the above timedatectl output is what I got as-is from a fresh Fedora 40 install without changing anything.
I suspect it wasn’t “after [network] synchronization” that your RTC changed to local time. That happened when you manually ran timedatectl set-time 10:47.
From the man page:
set-time [TIME]
Set the system clock to the specified time. This will also update the RTC time accordingly. …
timedatectl set-ntp yes only updated the operating system clock, not the hardware clock. To copy the OS time to the RTC, you need to run timedatectl set-local-rtc 0 (without--adjust-system-clock).
From the man page:
--adjust-system-clock
If set-local-rtc is invoked and this option is passed, the system clock is synchronized from the RTC again, taking the new setting into account. Otherwise, the RTC is synchronized from the system clock.
There are three clocks. 1) the network clock (NTP) 2) the operating system clock and 3) the hardware/BIOS clock (RTC). You normally want the data to flow from 1 to 2 to 3, but when you ran timedatectl set-local-rtc --adjust-system-clock 0, you caused 3 to copy to 2 (and you subsequently overwrote 2 a second time with timedatectl set-ntp yes). (Also, the way you entered that is odd. You shouldn’t put the --adjust-system-clock flag between the set-local-rtc command and its boolean value.)
This is what is confusing me. I ran timedatectl status twice after setting the time. The first time I get more or less what I expected except that system clock was not synchronized. The second time it was synchronized but RTC has changed to local time. Are you saying that timedatectl set-time doesn’t take effect immediately?
I tried again and it seems like the change happens when network synchronization is achieved. This is what I did,
~ ❯ sudo timedatectl set-ntp no
~ ❯ sudo timedatectl set-time 11:54
~ ❯ timedatectl status
Local time: Wed 2024-08-28 11:54:04 PKT
Universal time: Wed 2024-08-28 06:54:04 UTC
RTC time: Wed 2024-08-28 06:54:04
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
~ ❯ timedatectl status
Local time: Wed 2024-08-28 11:55:18 PKT
Universal time: Wed 2024-08-28 06:55:18 UTC
RTC time: Wed 2024-08-28 06:55:18
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
~ ❯ sudo timedatectl set-ntp yes
~ ❯ timedatectl status
Local time: Wed 2024-08-28 11:55:42 PKT
Universal time: Wed 2024-08-28 06:55:42 UTC
RTC time: Wed 2024-08-28 06:55:42
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
~ ❯ timedatectl status
Local time: Wed 2024-08-28 11:56:52 PKT
Universal time: Wed 2024-08-28 06:56:52 UTC
RTC time: Wed 2024-08-28 11:56:52
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
The steps are
Set ntp off and set time manually. Running timedatctl status shows RTC being same as UTC.
Wait a minute and run, timedatectl status again. RTC is still UTC.
Set ntp on. Running timedatectl status shows that is system clock is not synchronized and RTC is still UTC.
A littler later, timedatectl status shows that synchronization has happened and RTC is now local time.
Probably the most non-standard thing about my system is that I am running Asahi Linux on apple silicon. Searching web doesn’t find similar cases, so maybe this is some quirk of RTC on apple silicon?
Do you know for sure which time sync service your system is set to use (e.g. chrony or systemd-timesync)? If you have ntpd installed, you should probably remove it and use one of the newer services instead.
Have you customized the time service in any way? For example, if you are using chrony, try running sudo rpm -V chrony to see if any of its configuration files have been changed.
systemctl status will list all the running services. You might check there to make sure that what you think is enabled is actually running and that you don’t have multiple time services trying to run at the same time.
It looks like the rtcsync directive in /etc/chrony.conf might be causing the behavior you describe.
From man chrony.conf:
rtcsync
The rtcsync directive enables a mode where the system time is periodically copied to the RTC and chronyd does not try to track its drift. This directive cannot be used with the rtcfile directive.
On Linux, the RTC copy is performed by the kernel every 11 minutes.
On macOS, chronyd will perform the RTC copy every 60 minutes when the system clock is in a synchronised state.
Thanks a a lot! That was indeed the issue. Commenting out rtcsync does make RTC almost the same as UTC. I say almost because it seems like for some reason chrony seems to keep RTC about 20 seconds behind UTC.
~ ❯ timedatectl status
Local time: Thu 2024-08-29 19:54:11 PKT
Universal time: Thu 2024-08-29 14:54:11 UTC
RTC time: Thu 2024-08-29 14:53:51
Time zone: Asia/Karachi (PKT, +0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
I can use sudo timedatectl set-local-rtc --adjust-system-clock 0 and that aligns the RTC and UTC. However, they drift till RTC is 20 seconds behind UTC and then the difference stabilizes.
My guess is that the values in /etc/adjtime are incorrect. I don’t know how to correct them manually. I think it should correct itself eventually, but read the hwclock man page for more info.
I’m a little confused why you are seeing the results you are with rtcsync. My system has that setting enabled, but my RTC is kept in UTC time.
(later dual-boots I’d just temp-remove the Windows drive and later set Windows to UTC)