When I close the lid of my laptop, and resume later, the clock doesn’t keep time well. For example, when I closed the lid around 11 PM, when I open it at 8 AM, the time says something like 3:45 AM. This might be happening only when running on battery, but it has happened at least twice.
AMD Framework 13, Fedora 39, BIOS 3.03
Any suggestions what to check?
do you have ntp or sth like that enabled? for me the times hangs on all my laptops when put into sleep, well its sleeps 
when i resume ntp syncs time again after few secs and everything is back to normal ^^
Make sure automatic date and time is enabled in settings:
Ensure systemd time service is running:
systemctl status systemd-timedated.service
If it is not, start and enable it with:
sudo systemctl start systemd-timedated.service
sudo systemctl enable systemd-timedated.service
Shouldn’t the RTC on the mainboard keep ticking, even when the laptop is in sleep mode? The RTC uses either a small battery or uses a little bit from the main battery.
can we check for rtc status?
cat /proc/driver/rtc | grep batt
Thank you to everyone who has responded. It did not lose time last night while plugged in, so I don’t know if this is an ongoing thing or not.
@Loell_Framework
the response was:
batt_status : okay
also, for @gxnni suggestion:
systemctl status systemd-timedated.service
● systemd-timedated.service - Time & Date Service
Loaded: loaded (/usr/lib/systemd/system/systemd-timedated.service; static)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Wed 2023-11-15 07:38:30 CST; 17s ago
Docs: man:systemd-timedated.service(8)
man:localtime(5)
man:org.freedesktop.timedate1(5)
Main PID: 57740 (systemd-timedat)
Tasks: 1 (limit: 71853)
Memory: 1.2M
CPU: 30ms
CGroup: /system.slice/systemd-timedated.service
└─57740 /usr/lib/systemd/systemd-timedated
Nov 15 07:38:30 localhost.localdomain systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Nov 15 07:38:30 localhost.localdomain systemd[1]: Started systemd-timedated.service - Time & Date Service.
Cool! keep us posted on how the time/date is doing after the time & date service is enabled. 
I wonder if rtc_cmos.use_acpi_alarm=1 on kernel command line might help this case too?
It helps timer for wakeup from suspend then hibernate.
Just for another data point… I saw the same last night, although I’m running NixOS, and was plugged in. Looking at the logs, the system enters s2idle when I shut the lid at around 23:10, then wakes itself up at 23:59, so the system has kept time during this period of sleep. The system re-enters s2idle around 30 seconds later. At around 08:00 today I open the lid and the system shows midnight! I had to restart systemd-timesyncd to re-sync though I’m guessing it would have done so on it’s own eventually, but it doesn’t seem to do so very often looking at it’s log.
Thanks! I’ll give this a try and report back if I see it happen again. I’ve had the system since Monday, and I think this is the first time it’s behaved in this way, so I’m not sure if/when I’ll be able to confidently say it solves the issue.
Linux nixxy 6.1.62 #1-NixOS SMP PREEMPT_DYNAMIC Wed Nov 8 13:11:05 UTC 2023 x86_64 GNU/Linux
amd_pstate=passive cpufreq.default_governor=powersave initcall_blacklist=cpufreq_gov_userspace_init loglevel=4
Can you please attach a kernel log from a boot with this problem? You can look at historical boots using commands like these:
# journalctl -k -b-1
# journalctl -k -b-2
You might try this series depending on what’s in your log.
Hi Mario, here’s one: AMD Framework 13 RTC Issue - Pastebin.com
Notably, I have used rtc_cmos.use_acpi_alarm=1 during this.
Not sure if this is a red herring, but there are a number of these events in the log:
kernel: Unable to read current time from RTC
There’s patches coming in 6.8-rc1 that should help.