Manjaro/KDE randomly wrong time(many years ahead) after laptop sleep

Hello there,

I’m using manjaro linux on a lenovo laptop. In KDE time setting, the set date and time automatically option enabled.

When I open the laptop lid, the laptop wake from sleep state. And the system time randomly goes wrong.

Today is 2024.02.05, but the system time show the time is in 2078-03-11. After I reboot the system, the time is back to right.

Below are some logs:

Kernel version:

➜  ~ uname -a 
Linux lj-82y8 6.6.10-1-MANJARO #1 SMP PREEMPT_DYNAMIC Fri Jan  5 17:38:36 UTC 2024 x86_64 GNU/Linux

time info:

➜  ~ timedatectl 
               Local time: 五 2078-03-11 10:46:42 CST
           Universal time: 五 2078-03-11 02:46:42 UTC
                 RTC time: 一 2024-02-05 01:32:45
                Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
➜  ~ sudo hwclock --verbose 
hwclock from util-linux 2.39.3
System Time: 3414192410.960293
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1706183195 seconds after 1969
Last calibration done at 1706183195 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick... clock tick
Time read from Hardware Clock: 2024/02/05 01:32:55
Hw clock time : 2024/02/05 01:32:55 = 1707096775 seconds since 1969
Time since last adjustment is 913580 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2024-02-05 09:32:54.154743+08:00

and also I use the ntpd -qg the time also goes to be right

➜  ~ sudo ntpd -qg
11 Mar 10:48:55 ntpd[14790]: ntpd 4.2.8p17@1.4004-o Tue Jun  6 14:05:47 UTC 2023 (1): Starting
11 Mar 10:48:55 ntpd[14790]: Command line: ntpd -qg
11 Mar 10:48:55 ntpd[14790]: ----------------------------------------------------
11 Mar 10:48:55 ntpd[14790]: ntp-4 is maintained by Network Time Foundation,
11 Mar 10:48:55 ntpd[14790]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
11 Mar 10:48:55 ntpd[14790]: corporation.  Support and training for ntp-4 are
11 Mar 10:48:55 ntpd[14790]: available at
11 Mar 10:48:55 ntpd[14790]: ----------------------------------------------------
11 Mar 10:48:55 ntpd[14790]: DEBUG behavior is enabled - a violation of any
11 Mar 10:48:55 ntpd[14790]: diagnostic assertion will cause ntpd to abort
11 Mar 10:48:55 ntpd[14790]: proto: precision = 0.040 usec (-24)
11 Mar 10:48:55 ntpd[14790]: basedate set to 2023-05-25
11 Mar 10:48:55 ntpd[14790]: gps base set to 2023-05-28 (week 2264)
11 Mar 10:48:55 ntpd[14790]: Listen and drop on 0 v6wildcard [::]:123
11 Mar 10:48:55 ntpd[14790]: Listen and drop on 1 v4wildcard
11 Mar 10:48:55 ntpd[14790]: Listen normally on 2 lo
11 Mar 10:48:55 ntpd[14790]: Listen normally on 3 wlp1s0
11 Mar 10:48:55 ntpd[14790]: Listen normally on 4 lo [::1]:123
11 Mar 10:48:55 ntpd[14790]: Listen normally on 5 wlp1s0 [2409:895e:de7c:5593:1bc1:c833:7803:5a03]:123
11 Mar 10:48:55 ntpd[14790]: Listen normally on 6 wlp1s0 [fe80::db77:3b51:f040:e616%2]:123
11 Mar 10:48:55 ntpd[14790]: Listening on routing socket on fd #23 for interface updates
 5 Feb 09:35:07 ntpd[14790]: ntpd: time set -1707095636.715332 s
ntpd: time set -1707095636.715332s

I don’t know why this happens and how can I solve this?


Welcome to the forum. I’m just fishing for clues here, but what are the outputs of

systemctl status systemd-timesyncd.service


timedatectl timesync-status
1 Like

Hi @llj098, and welcome!

In addition to what @Takakage said, perhaps this will help:

Also, make sure your setting in BIOS/UEFI is correct.

1 Like

CMOS Battery? On reboot syncs through internet. In deep sleep relies on the battery for RTC.

1 Like

I like configuring a script to sync time according to network on every net connection.
(which, depending on configuration, would also fire after sleep/suspend)

1 Like

Thanks for the reply, right now the time is correct( goes wrong randomly)

the output:

➜  ~ systemctl status systemd-timesyncd.service

● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2078-03-12 02:00:11 CST; 54 years 1 month ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 25679 (systemd-timesyn)
     Status: "Idle."
      Tasks: 2 (limit: 33234)
     Memory: 1.5M (peak: 2.2M)
        CPU: 27ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─25679 /usr/lib/systemd/systemd-timesyncd

2月 06 08:36:03 lj-82y8 systemd[1]: Starting Network Time Synchronization...
3月 12 02:00:11 lj-82y8 systemd-timesyncd[25679]: System clock time unset or jumped backwards, restored from recorded timestamp: Sat 2078-03-12 02:00>
3月 12 02:00:11 lj-82y8 systemd[1]: Started Network Time Synchronization.
2月 06 08:36:01 lj-82y8 systemd-timesyncd[25679]: Contacted time server (
2月 06 08:36:01 lj-82y8 systemd-timesyncd[25679]: Initial clock synchronization to Tue 2024-02-06 08:36:01.840166 CST.

➜  ~ timedatectl timesync-status

       Server: (
Poll interval: 2min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C23ACA14
    Precision: 1us (-25)
Root distance: 1.090ms (max: 5s)
       Offset: +29.556ms
        Delay: 285.797ms
       Jitter: 40y 10month 3w 1d 1h 15min 33.591136s
 Packet count: 4
    Frequency: +11.055ppm

Thanks for reply! I have already checked the link you post. But I have linux system on this laptop only.

And My time goes to Mar 2073, so It should not be the timezone issue?


Thanks for the reply! I’m using a new laptop, it seems not a battery issue.

How can I determine if it is a battery issue?


Thanks for the link!

As my time goes to 2073, so it shoud not be a timezone issue?

update, If the system wake up, and there is no internet connection, where time will be wrong,

It happens everyday now, anyone can help?


Sorry dude,


Sounds like your BIOS/UEFI is out of whack…

Thanks for the reply, I just check the BIOS, the time is correct. What should I do to make sure the BIOS/UEFI issue? BTW, it is a new laptop, I just buy it two weeks ago.

This issue only happens when the laptop wake up after long(1 hour or longer sleep).

Only other thing I can suggest is checking the status of the systemd-timesyncd.service service:

systemctl status systemd-timesyncd.service

Additionally, what @cscs said, looks like a valid option to me:

So check the link he gave:

I just found an old thread(2013), Clock shifted to the future after suspend/resume / Kernel & Hardware / Arch Linux Forums It seems that I have the exact same issue.

My log shows

           Local time: 五 2078-03-11 10:46:42 CST
       Universal time: 五 2078-03-11 02:46:42 UTC
             RTC time: 一 2024-02-05 01:32:45

For my understanding, RTC time is hardware clock, the hardwire clock shows the right time, why do you say it is the bios’s problem?


It does, and I don’t think there’s a fix for it. Or st least, I couldn’t find one.

So I suggest one of two thing:

  1. Go with the advice @cscs gave you as a workaround; or
  2. Reinstall Manjaro and see if the problem persists, and if it does, then you’ll have to apply #1.


That was my understanding. But your link says differently:

Yes, it seems to be a kernel bug.

That was my understanding because this is the first time I’ve heard of it in 15+ years!

What does the Manjaro Settings Manager (manjaro-settings-manager) show when you open it and select the “Time and Date” section? This is what my system, which always has the correct time (even after sleeping), shows:

1 Like

To set system time from hardware clock

sudo hwclock --hctosys

Thank you all guys. I think this is not a hardware problem.

I use two script to solve this. First script: /lib/systemd/system-sleep/time-shift

case $1/$2 in
    date +%s >> /tmp/suspend.log
    date +%s >> /tmp/wakeup.log
    hwclock --hctosys
    date +%s >> /tmp/wakeup_shifted.log

second script:

➜  ~ cat /etc/NetworkManager/dispatcher.d/09-synctime 

case "$2" in
        date +%s > /tmp/before_ntp.log
        ntpd -qg
        date +%s > /tmp/after_ntp.log
1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.