All of a sudden Day Date 1 day behind

I rebooted my fedora 37 VM, and 1 application started to dispaly the following error

Warning: Error fetching server time: Detected 50496.27999997139 seconds time difference between your browser and the server.

I discovered that day date was 1 day behind, so today is October 6 and in fedora UI I see October 5th. I tried to chnage it manually but it was not possible even when I log as root.

When I issue
timedatectl status
> Local time: Thu 2023-10-05 20:58:11 CEST

       Universal time: Thu 2023-10-05 18:58:11 UTC
             RTC time: Thu 2023-10-05 18:55:04
            Time zone: Europe/Paris (CEST, +0200)

System clock synchronized: no
NTP service: active
RTC in local TZ: no

I tried
timedatectl set-local-rtc 0
but it did not help.
As indicated this happened suddenly and datetime was Ok for more than 2 years. So what might changed or lead to this behavior and how can I fix it?
Thanks in advance

Many systems have a hardware clock powered by a small battery when the system is off. Check the user manual to see if your system uses such a battery and find out how to replace it. If you can remove the battery and have access to a voltmeter you can check that it provides the correct voltage. In my experience, clock problems occur when the voltage is substantially lower than the rated value. You also find that replacing the battery resets BIOS options if you are not using defaults.

George it is a VM on a physical server that hosts other fedora and centos machines without any problem

systemctl status systemd-timesyncd.service chronyd.service

Here is what I get

systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; preset: disabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)

●> chronyd.service - NTP client/server

 Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
 Active: active (running) since Thu 2023-10-05 14:33:40 CEST; 11h ago
   Docs: man:chronyd(8)
Process: 656 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)

Main PID: 669 (chronyd)
Tasks: 1 (limit: 6845)
Memory: 4.9M
CPU: 188ms
CGroup: /system.slice/chronyd.service
└─669 /usr/sbin/chronyd -F 2

Oct 05 14:33:39 fedora chronyd[669]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS >
Oct 05 14:33:39 fedora chronyd[669]: Frequency 12.258 +/- 1.217 ppm read from /var/lib/chrony/drift
Oct 05 14:33:39 fedora chronyd[669]: Using right/UTC timezone to obtain leap second data
Oct 05 14:33:39 fedora chronyd[669]: Loaded seccomp filter (level 2)
Oct 05 14:33:40 fedora systemd[1]: Started chronyd.service - NTP client/server.
Oct 05 14:33:53 chronyd[669]: Selected source (
Oct 05 14:33:53 chronyd[669]: System clock TAI offset set to 37 seconds
Oct 05 20:12:22 chronyd[669]: Can’t synchronise: no selectable sources
Oct 05 20:17:45 chronyd[669]: Selected source (
Oct 05 20:17:45 chronyd[669]: System clock wrong by 50593.841437 seconds

Check your NTP sources:

sudo chronyc -N sources -a

Try replacing chronyd with systemd-timesyncd:

sudo systemctl --now disable chronyd.service 
sudo systemctl --now enable systemd-timesyncd.service

I am not familiar with using right/UTC. Did a leap second occur where the use of right/UTC side effects caused this? Are your other working systems using right/UTC?

Do you run ntpdate.service?

Even if you switch to systemd-timesyncd.service and it fixes everything I am curious to know root cause on this problem.

When I issue

[root@fedora ~]# chronyc -N sources -a
I get

506 Cannot talk to daemon

When I check the status as follows

[root@fedora ~]# systemctl status ntpdate.service

Unit ntpdate.service could not be found.

Stephen, here is the output of the command
timedatectl status
on a second fedora 37 VM

      >   Local time: Fri 2023-10-06 18:15:45 CEST
       Universal time: Fri 2023-10-06 16:15:45 UTC
       RTC time: Fri 2023-10-06 16:15:45
       Time zone: Europe/Paris (CEST, +0200)
       System clock synchronized: yes
       NTP service: active
       RTC in local TZ: no

which has System clock synchronized: yes

Vladislav, Stephen,

I dfont know why, all of a sudden when I was trying checking some services according to Vladislav, I just noticed that right now date and time are correct on the fedora that was having the issue !!!

This looks correct. Local time is UTC +2 and RTC is set to UTC as it normally should be.

If RTC is set to local time then time shifts may occur. The system is designed for RTC == UTC and everything is based on that premise.

Note that there may have been a recent update to time zone data and it would require a reboot for those changes to become stable in display.

The rules for Europe/Paris hasn’t changed for many years.

Looks like the journal message showing right/UTC comes from chrony.conf

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

which means leap second days have more that 24hr worth of seconds. I guess everything in fedora can handle it which is great.

Is this a qemu-kvm guest? Do you run qemu-guest-agent services in your guests? What I’ve read recommends runing ntp in guests but the clock sync that happens with qemu-ga may solve this issue.

Otherwise installing/configuring ntpdate.service may help in your case. Since ntpdate sets the clock imediately and chronyd.service does not start until after ntpdate, if there is a skew on boot it will be reset during boot. It seems logical to me that the same could be done with chrony but I did not find any examples. Authoring a custom service maybe?

That chrony converged the system to the correct time even with a large initial skew is pretty amazing. I don’t know if systemd-timesyncd or ntpd or any other ntp client does any differently. The chrony project claims they do it better in that 2015 FAQ.

The total number of leap seconds ever applied is 37 seconds, that is the difference between TAI time and UTC time. On 31 December at 24:00 UTC there might be another one applied, or perhaps not.

Some NTP clients won’t start if the difference between the system time and network time is too great. chronyd can do large time jumps. journalctl should show significant clock events.

I think systemd timesyncd won’t run if ntpsec or chrony is installed.

Earth’s rotation speed slowed for years, but has increased in recent years:
Earth’s rotation affects eclipses. There is a possibility that some software doesn’t handle negative leap seconds.

From the log it looks like something has stepped the VM’s clock while it was running. chronyd in the default configuration is allowed to correct the clock by step only on start. If something disturbs the clock later, chronyd would try to correct it slowly be slewing, but with such a large offset it would take few weeks to correct. If you cannot find and fix the problem that caused the clock step, you might need to allow chronyd to correct by step at any time by changing makestep in chrony.conf to 1 -1.